Hi Mark,
> On Tue, Jun 11, 2002 at 10:14:48AM -0700, Maksim Yevmenkin wrote:
> > or USB dongle. They all MUST talk via HCI. So HCI is not really a
> > device driver, and, IMO, it is not a pseudo device driver. It sort
> > of looks like /dev/tcp :)
>
> A ng_device netgraph node is coming up.
> Th
On Tue, Jun 11, 2002 at 10:14:48AM -0700, Maksim Yevmenkin wrote:
> or USB dongle. They all MUST talk via HCI. So HCI is not really a
> device driver, and, IMO, it is not a pseudo device driver. It sort
> of looks like /dev/tcp :)
Hi Maksim,
A ng_device netgraph node is coming up.
That will pres
About 1 year ago, I ported a proprietary linux driver to FreeBSD 4.x.
I needed to support linux binaries which use device cloning. I came
up with the following hack. The Linux driver code I ported from is
under NDA, but I feel safe in posting this with the names obscured.
The just of it is that
Harti Brandt wrote:
> You just don't know what you are talking about. This is exactly the
> difference between the current Linux sound (1 device) and FreeBSD (1
> device/channel). In FreeBSD I can use N channels with different audio
> formats and speeds, in Linux I'm stuck to using all the channel
On Tue, 11 Jun 2002, Terry Lambert wrote:
TL>Harti Brandt wrote:
TL>> TL>For a sound device, it would be nice if multiple instances to the
TL>> TL>devices were mux'ed. I've had cases where the program I was using
TL>> TL>was using a smaller number that the total available channels, and
TL>> TL>i
Maksim Yevmenkin wrote:
> Well, HCI _IS_NOT_ a network protocol like TCP or even UDP. It is a
> predefined set of control messages and events that user might send
> to the device. L2CAP which is runs over HCI _IS_ a network protocol
> and it is implemented in AF_BLUETOOTH protocol family. So appli
Maksim Yevmenkin wrote:
> I'm sorry people :) I should have been more specific. Here is
> what i meant. I'm working on Bluetooth stack for FreeBSD. Everything
> is implemented in Netgraph. The real device driver nodes are connected
> to HCI layer. You can talk to any Bluetooth device via HCI layer
Harti Brandt wrote:
> TL>For a sound device, it would be nice if multiple instances to the
> TL>devices were mux'ed. I've had cases where the program I was using
> TL>was using a smaller number that the total available channels, and
> TL>it would have been nice if the next open instance got the r
> >I'm sorry people :) I should have been more specific. Here is
> >what i meant. I'm working on Bluetooth stack for FreeBSD. Everything
> >is implemented in Netgraph. The real device driver nodes are connected
> >to HCI layer. You can talk to any Bluetooth device via HCI layer. It
> >does not re
In message <[EMAIL PROTECTED]>, Maksim Yevmenk
in writes:
>I'm sorry people :) I should have been more specific. Here is
>what i meant. I'm working on Bluetooth stack for FreeBSD. Everything
>is implemented in Netgraph. The real device driver nodes are connected
>to HCI layer. You can talk to any
Hackers,
[...]
> TL>I don't think the original poster wanted cloning for support on
> TL>physical devices for which there was a 1:1 relationship anyway
> TL>(8^)), but there *are* cases where it could be useful.
> TL>
> TL>Actually, I think the original poster never really disclosed *what*
> TL>
On Tue, 11 Jun 2002, Terry Lambert wrote:
TL>Harti Brandt wrote:
TL>> I was talking about real devices, not pseudo devices that you can get out
TL>> of thin air. Device driver for real devices should be just what they are:
TL>> device drivers. If you take a disk driver, then there is no code ther
Harti Brandt wrote:
> I was talking about real devices, not pseudo devices that you can get out
> of thin air. Device driver for real devices should be just what they are:
> device drivers. If you take a disk driver, then there is no code there
> that tries to present multiple contexts to multiple
On Tue, 11 Jun 2002, Terry Lambert wrote:
TL>Harti Brandt wrote:
TL>> In MHO this idea is based on a fundamental misunderstanding of what a
TL>> device is under unix. If you need such a behaviour you should put another
TL>> abstraction on top of you devices (as the filesystem is put on top of
TL>
Harti Brandt wrote:
> In MHO this idea is based on a fundamental misunderstanding of what a
> device is under unix. If you need such a behaviour you should put another
> abstraction on top of you devices (as the filesystem is put on top of
> disks and sockets on top of network devices), that handl
On Mon, 10 Jun 2002, Maksim Yevmenkin wrote:
MY>Hackers,
MY>
MY>The project i'm working on might require some sort of
MY>device cloning. The current way of cloning, i.e. use
MY>DEVFS and allocate unique minor numbers, is not very
MY>good for my purpose.
MY>
MY>The idea is simple: the same device(
On Tue, 2002-06-11 at 06:45, Poul-Henning Kamp wrote:
> >The idea is simple: the same device(major,minor) can
> >be opened several times by different processes (or
> >possibly threads within the same process) and each
> >process (thread) will have unique device instance.
>
> Sorry, but this wont
"Vladimir B. Grebenschikov" wrote:
> As far as I understand _key_ word is "open", each new instance appears
> on open(), but fork() and dup() only do regular work. dup'ed or fork'ed
> descriptors will be same from driver's point of view, but each new
> open() will create new instance.
No.
The pr
÷ Tue, 11.06.2002, × 01:15, Poul-Henning Kamp ÎÁÐÉÓÁÌ:
> In message <[EMAIL PROTECTED]>, Maksim Yevmenk
> in writes:
> >Hackers,
> >
> >The project i'm working on might require some sort of
> >device cloning. The current way of cloning, i.e. use
> >DEVFS and allocate unique minor numbers, is not v
In message <[EMAIL PROTECTED]>, Maksim Yevmenk
in writes:
>Hackers,
>
>The project i'm working on might require some sort of
>device cloning. The current way of cloning, i.e. use
>DEVFS and allocate unique minor numbers, is not very
>good for my purpose.
>
>The idea is simple: the same device(majo
20 matches
Mail list logo
