I think is the trivial drivers, and if no
problems are reported I will sweep all these drivers for cdevsw_add()
related code and commit it one by one.
If you know any of the drivers involved and know for sure that the
driver is covered with make_dev() calls (ie: it works correctly on
DEVFS systems) pl
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 _prob
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
just checking'.
Nick.
On Fri, 4 Jun 1999, Poul-Henning Kamp wrote:
> 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);
> >
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
>th
17 matches
Mail list logo
