Re: Migrating to larger numbers
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 8 Jun 1999 22:24:30 +1000
Matt Aubury writes:
>
> On Tue, Jun 08, 1999 at 12:37:59PM +1000, Richard Gooch wrote:
> > No, devfs doesn't put policy into the kernel. It replaces policy in
> > existing device drivers: from magic device numbers to device names.
> > And of course it doesn't prevent you from using your own favorite
> > device names if you really want.
>
> I may regret getting into this, but here goes.
>
> I had to write a modular device driver recently, and wanted to have
> access to lots of minor numbers but without getting my own major
> number allocation. I couldn't expect "customers" to start using devfs,
> so that was out.
>
> What I did was this:
>
> -- Do dynamic major allocation in the usual way.
> -- Report the allocation (and other stuff) via /proc.
> -- The startup script run by init uses the information in /proc
> to create the appropriate inodes.
>
> Now this may seem, er... hacky, but I actually think it achieves the
> rather sensible aims of devfs without the pain. The string lookup
> mechanisms are now just part of normal filesystem operation, and it's
> completely dynamic so pretty well future proofed.
Less pain with devfs.
> It's not the right choice for the more important drivers in the
> kernel, but for purely modular drivers (those which really do need
> to be in kernel space), I think it makes a wad of sense. What do the
> other protagonists feel?
This case just demonstrates a looming problem. If hardware
manufacturers take the leap and write Linux drivers, there has to be
some scheme where they can allocate device entries. With devfs there
is less scope for conflicts. They can't all go running to Peter for an
allocation in devices.txt.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/