Basically I'm not working on devfs at the moment since the bit that made
it workable was ripped out with extreme prejudice by someone. I'm still
absolutly convinced that a dynamic device registration and export
framework is required in the long run, but I'm not fussed if it's based on
the current
On Sat, 5 Jun 1999, Poul-Henning Kamp wrote:
> In message , Nick Hibma
> writes:
> > > >While on the topic: Who is working on devfs and why not?
> > >
> > > I'm not currently working on devfs, but I am building the infrastructure
> > > it should be based on in the kernel.
> >
> >Anymore infor
In message , Nick Hibma
writes:
> > >While on the topic: Who is working on devfs and why not?
> >
> > I'm not currently working on devfs, but I am building the infrastructure
> > it should be based on in the kernel.
>
>Anymore information available on where you are with this?
I currently have a
> >While on the topic: Who is working on devfs and why not?
>
> I'm not currently working on devfs, but I am building the infrastructure
> it should be based on in the kernel.
Anymore information available on where you are with this?
Cheers,
Nick
To Unsubscribe: send mail to majord...@
In message , Nick Hibma
writes:
>
>While on the topic: Who is working on devfs and why not?
>
>I'd like to know whether there is some interest in getting that work
>underway again. More than interested to help.
I'm not currently working on devfs, but I am building the infrastructure
it should be
While on the topic: Who is working on devfs and why not?
I'd like to know whether there is some interest in getting that work
underway again. More than interested to help.
> You're forgetting that devsw[] is another stopgap. The kernel should
> probably use something like devfs, where dev_t'
In message <199906042048.gaa25...@godzilla.zeta.org.au>, Bruce Evans writes:
>You're forgetting that devsw[] is another stopgap. The kernel should
>probably use something like devfs, where dev_t's only exist for devices
>that actually exist. xxx_init() is far too early to decide which hardware
>
>> The isa drivers provide many bad examples. Most of them attached the
>> devsw in a disgusting SYSINIT even if the device is disabled. I moved
>> the devsw attach to the device attach function in some drivers that
>> I worked on. This was necessary to support pcvt and syscons sharing a
>> devs
On Sat, 5 Jun 1999, Bruce Evans wrote:
> >> Hm, I think this a bad choice. Which are 'all the other drivers'? The
> >> probe should really be as thin as possible to avoid unnecessary delays
> >> when probing in a kernel, like GENERIC, with a lot of device drivers
> >> compiled in.
> >
> >Well, in
On Sat, 5 Jun 1999, Bruce Evans wrote:
>
> The isa drivers provide many bad examples. Most of them attached the
> devsw in a disgusting SYSINIT even if the device is disabled. I moved
> the devsw attach to the device attach function in some drivers that
> I worked on. This was necessary to su
>> Hm, I think this a bad choice. Which are 'all the other drivers'? The
>> probe should really be as thin as possible to avoid unnecessary delays
>> when probing in a kernel, like GENERIC, with a lot of device drivers
>> compiled in.
>
>Well, in the PCI drivers, it is just the meteor, the brooktre
Nick
> Hm, I think this a bad choice. Which are 'all the other drivers'? The
> probe should really be as thin as possible to avoid unnecessary delays
> when probing in a kernel, like GENERIC, with a lot of device drivers
> compiled in.
Well, in the PCI drivers, it is just the meteor, the brooktr
> I've just fixed the bt848 driver (bktr) where the
> cdevsw_add() was accidentally added to the BSDI bktr_probe()
> and not the FreeBSD bktr_probe.
>
> Although Bruce and Nick said this really belongs, in the _attatch()
> function, I've kept it in the _probe() function for consistency
> w
Nick Hibma wrote:
> > cdevsw_add()
> This should definitely go into attach IMNSHO.
>
> Probe: Check whether hardware is there (no side effects if possible).
> Attach:Get the device up and running and integrated into the kernel.
>
> With the priority probes this is even more distinct as a priori
This should definitely go into attach IMNSHO.
Probe: Check whether hardware is there (no side effects if possible).
Attach:Get the device up and running and integrated into the kernel.
With the priority probes this is even more distinct as a priority not
equal to 0 means 'no side effects, just c
In message <3757c851.4...@cs.strath.ac.uk>, Roger Hardiman writes:
>Hi there,
>
>Just a quick question.
>I'm about to fix the cdevsw_add(&bktr_cdevsw);
>bug in the brooktree848.c driver.
>
>Bruce wondered if this should go into bktr_attatch rather
>than bktr_probe?
>
>What do you think?
>I th
16 matches
Mail list logo
