Date: Wed, 26 Jul 2000 09:56:11 +0200 From: Adrian Chadd <adrian@freebsd.org> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000726095611.B68912@ywing.creative.net.au> In-Reply-To: <Pine.BSF.4.05.10007251730500.16927-100000@semuta.feral.com>; from mjacob@feral.com on Wed, Jul 26, 2000 at 12:10:50AM -0700 References: <20000726023506.A68912@ywing.creative.net.au> <Pine.BSF.4.05.10007251730500.16927-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 26, 2000, Matthew Jacob wrote: > You could sort of do that too. You've described two organizational systems > (disklabels, vinumvolumes) which are both valuable and persistent (once you > make a disklabel and once you make a vinumvolume). > > Your other example isn't quite how things are working or what I'm getting at. [snip fibre channel explanation bits, thanks!] > It's more than drivers. It's also collection subsystems. What I really > envision for Fibre Channel is an FC4 layer that each FC host adapter registers > entities with (as a WWN,PortID,PortType)- these would be a one-to-many mapping > because you could have access to the same device on multiple FC ports > (particularly for fabrics). Right now this FC4 layer in FreeBSD lives solely > in the portdb part of the fcparam part of the Qlogic driver's softc (see > sys/dev/isp/ispvar.h, ~line 253), but hopefully we'll have a second FC > solution for FreeBSD in 5.0 (I'm thinking about the LSI-Logic card)- in which > case this info needs to be shared somewhere- and it's not really a CAM thingie > because FC-IP (Fibre Channel-IP) entities can/will be there as well. > Sorry- longwinded comment, but the point here is that this info doesn't and > shouldn't fit into the 'driver to be polled' model. ok. There should not be a reason why you can't simply register your FC devices as '/dev/fc/$label' or even '/dev/$label' rather than '/dev/da1a'. A "true" devfs would not pretend to impose a "%s%d", majorstring, minorunit type namespace in front of all devices, and so neither should you. If you have a generic FC layer which handles mapping physical devices to logical devices, I can't see a problem here. Without understand how the disklabel code works, I then can't see a reason why a generic 'disklabel' layer can't be introduced for interested devices to supply their own label rather than be given da/ad -- and furthering that, register multiple device names for the same devsw. The addalias and friends in the existing VFS code will handle multiple namespace entries for the same device, which is what works right now. Have I missed anything? -- Adrian Chadd Now 17-year-olds can't play a _video game_ <adrian@FreeBSD.org> because its called violent - and real violence is still called dinner. -- jamie@mccarthy.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000726095611.B68912>