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
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
h open instances to the
TL>device that exports the VMWare kernel context information to the
TL>user space application: because FreeBSD lacks device cloning.
TL>
TL>Rather than trying to say what someone should do, it'd be nice,
TL>at least in the case of commercial code that ca
t run more than one VMWare seassion at a time
because it lacks the ability to distinguish open instances to the
device that exports the VMWare kernel context information to the
user space application: because FreeBSD lacks device cloning.
Rather than trying to say what someone should do, it
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 id
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
> >
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.
>
>
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(major,minor) can
be opened several times by different processe
Hackers,
Attached some patches that implements device cloning
(with devfs(5) support) for tap(4). The implementation is based
on resource manager (see tun(4) and gif(4)).
Brooks Davis ([EMAIL PROTECTED]) took a quick
look at the patch and seems has no objection. Please review
Hackers,
Below some patches that implements device cloning (with devfs(5)
support) for tap(4) device. The implementation is based on resource
manager (just like tun(4) and gif(4)). Please review, test and if
there is no objection commit. If there are any problems, please let
me know.
http
This patch slightly changes the way device cloning works.
After the cloners have been called we try to find the match
not by name but by the dev_t the successfull cloner gave us.
This allows "cloning by a different name" activities.
The patch to kern
24 matches
Mail list logo
