[openbeos] Re: Add-ons/Module problems/ideas??
- From: "Manuel Jesus Petit de Gabriel" <freston@xxxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Wed, 31 Jul 2002 20:25:18 -0700
----- 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: