
|
[openbeos]
||
[Date Prev]
[08-2002 Date Index]
[Date Next]
||
[Thread Prev]
[08-2002 Thread Index]
[Thread Next]
[openbeos] Re: Add-ons/Module problems/ideas??
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 01 Aug 2002 13:08:33 +0200 (MEST)
Thx, but that I know already :)))))
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.
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
>
>
>
|

|