[openbeos] Re: Add-ons/Module problems/ideas??
- From: "Manuel Jesus Petit de Gabriel" <freston@xxxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Thu, 1 Aug 2002 08:34:46 -0700
> Thx, but that I know already :)))))
I was no answering you, but Philippe Houdouin! :)))
> I rewrote the rescan command that did just this :^)
> My concern was if kernel modules could do this safely,
> *without deadlocking* devfs,
> *without stack overflow* if we deal with recursing calls.
But looks like the answer also applies to you... :))
He asked: "what does usbd do?"... well that's what usbd does. :)
manuel,
>
> François.
>
> En réponse à Manuel Jesus Petit de Gabriel <freston@xxxxxxxxxxx>:
>
> >
> > ----- Original Message -----
> > From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
> > To: <openbeos@xxxxxxxxxxxxx>
> > Sent: Wednesday, July 31, 2002 8:24 AM
> > Subject: [openbeos] Re: Add-ons/Module problems/ideas??
> >
> >
> > > François wrote:
> > > > However I've been wondering about issues like rescanning, but I
> > still
> > want to
> > > > see how usb mosules deals with this before complaining =)
> > >
> > > The way "usbd" module ask devfs to reload the driver who register
> > him
> > > wanting being notified when some specified USB device(s) appear or
> > disapper
> > > on USB bus is unknown, that's right.
> >
> > #include <unistd.h>
> > #include <fcntl.h>
> > #include <string.h>
> >
> > int
> > main(int argc, char **argv)
> > {
> > for(int i= 1; i< argc; i++) {
> > int h= open("/dev", O_RDWR, 000);
> > write(h, argv[i], strlen(argv[i]));
> > close(h);
> > }
> >
> > return 0;
> > }
> >
> > // You are welcome,
> >
> >
> > manuel,
> >
> > PS: maybe there is some typo, but you get the idea.
> >
> > > In fact, the USBD way of doing was said to be a prototype of a new,
> > more
> > > dynamic, driver API by Be Inc. engineer in some BNewsletter (can't
> > find
> > > it now, sorry). We'll have to look at this issue, but Michael Phibbs
> > > don't plan binary compatibility with USB drivers, or did I miss
> > something
> > > here?
> > >
> > > > Wondering also if we need to keep modules from publishing devfs
> > entries
> > > > and leave that to drivers, or we could allow both.
> > > > While it could bemore flexible, it could also become a real mess
> > faster
> > :)
> > >
> > > Well, nothing prevent one binary image to export both driver API
> > > ("init_driver", "publish_devices", etc) and kernel module(s) API
> > > ("modules" data symbol).
> > >
> > > If a kernel module need to publish a /dev/* entry, why it's not a
> > > *driver* instead?
> > > If some part of his code need to be (re)used by another driver(s),
> > > let's split it into a module and a driver (even in the same binary
> > > file!)... it's a the purpose of kernel modules, in fact.
> > >
> > > -Philippe
> >
> >
> >
>
>
>
>
>
Other related posts:
