Date: Thu, 18 Dec 1997 19:16:42 -0800 From: Julian Elischer <julian@whistle.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Mike Smith <mike@smith.net.au>, Darren Reed <avalon@coombs.anu.edu.au>, freebsd-hackers@freebsd.org Subject: Re: converting drivers to dynamic memory... Message-ID: <3499E71A.167EB0E7@whistle.com> References: <19971218065107.10999@hydrogen.nike.efn.org> <199712182230.JAA01661@word.smith.net.au> <19971218145005.37073@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote:
For compatibility with the existing system,
devfs accesses all the devices through the standard
major/minor system.
this si so that the same driver can run with both devfs and
non-devfs systems.
The AIM is that after a cut-over to devfs,
drivers could be modified to take more generalised arguments.
the minor number can be interpretted as a cookie that can be used to
look something up in a hash-table or similar.
That's what I do in slice/slice_device.c
the minor number there is just a cookie, that is used to find
a softc structure. In a more generalised situation.
the minor could be used to find a small structure
which in turn contains a pointer to the softc, plus a unique
sub-identifier.
eventually, the minor number might be interpretted directly as a
pointer to this structure.
Since teh minor number is supplied by the driver and never
alterable by the user, this is safe. it might also be
possible to make it not print out at all in 'ls'
as that would just be confusing.
What I'm saying is that the minor number can be interpretted
as the driver sees fit, however in the current system it must
be a static thing and that is very limiting. (not to mention
we only have 24 bits)
>
> Mike Smith scribbled this message on Dec 19:
> > > yep, I think that would be a great addition... IMO, once devfs has
> > > finally been completed, we will still need a minor number of the void *
> > > (I happen to like the name dev_info_t), the minor so that we know what
> > > part of the device driver we are accessing... else we would need to
> > > allocate a bunch of small structs like:
> > > struct {
> > > int option;
> > > struct devicedata data;
> > > }
> > >
> > > which would be really wasteful of precious memory resources...
> >
> > No. I take your point about wanting to have multiple DEVFS entries
> > referencing a single softc structure though; you might want to have
> > something like:
> >
> > struct devfs_softc_reference
> > {
> > void *softc;
> > int token;
> > }
> >
> > inside the devfs_node structure.
>
> yep, that's what I'd like...
>
> > Forget the btree model; it's not going to fly in the face of a direct
> > reference approach.
>
> I will once devfs and the driver interface supports it... but devfs and
> the interface doesn't even support passing a token yet (well, it does if
> you call minor number a token)... I just proposed a simple stop gap
> meassure that would get the ball rolling..
>
> when did I ever say that we should in the long run choose using a
> btree over the "correct" way to do it?? I only said it would require
> an interface change (which hasn't even started to happen, sure the
> devfs code is in place, but actually USING it to pass tokens hasn't
> even begun), which I stated, I wasn't going to do... but I proposed
> using the btree method as a stepping stone to get to the final
> destination...
>
> --
> John-Mark Gurney Modem/FAX: +1 541 683 6954
> Cu Networking P.O. Box 5693, 97405
>
> Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3499E71A.167EB0E7>