From owner-freebsd-hackers Thu Dec 18 19:20:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA15573 for hackers-outgoing; Thu, 18 Dec 1997 19:20:48 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15564 for ; Thu, 18 Dec 1997 19:20:44 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA24307; Thu, 18 Dec 1997 19:19:29 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd024302; Thu Dec 18 19:19:28 1997 Message-ID: <3499E71A.167EB0E7@whistle.com> Date: Thu, 18 Dec 1997 19:16:42 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: John-Mark Gurney CC: Mike Smith , Darren Reed , freebsd-hackers@freebsd.org Subject: Re: converting drivers to dynamic memory... References: <19971218065107.10999@hydrogen.nike.efn.org> <199712182230.JAA01661@word.smith.net.au> <19971218145005.37073@hydrogen.nike.efn.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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