Date: Wed, 26 Jul 2000 00:10:50 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <Pine.BSF.4.05.10007251730500.16927-100000@semuta.feral.com> In-Reply-To: <20000726023506.A68912@ywing.creative.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Right, so if I understand all this discussion right, you want to be able > to take a name which can represent a changing target, and present that > in devfs, correct? > > Being totally naieve(sp?) here, but why can't you just tie in the devfs > namei() into newbus somehow? Is there any reason why you can't have some > form of device hierarchy inside /dev besides the (mostly) flat namespace > that already exists? > > Think things like vinum. I like the /dev/vinum/volumename abstraction. If > you are doing Fibrechannel stuff (which I'll admit I know *nothing* about) > and you want to be able to reference a target which could possibly change > between reboots, why not just have the CAM subsystem register /dev/scsi/ > with devfs, and handle things itself in there? Or, you could abstract it > further, and have /dev/disklabel/<disklabelname> and let the disklabel > code handle mapping a name to a device? 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. If I have a pure parallel (SPI) SCSI disk device, I have something which is physically addressable as a <SCSI Target ID, LUN> (more formally, an ITLQ Nexus). This, depending on the order of other things around and, possibly, the forced binding in a config file, is then addressed by the system as the da device, unit N. But if you physically change the bus and or subtract other devices, that which was daN at one time is now daM. If I have a Fibre Channel device, it is emulating a SCSI disk device- that is, you still present to it as a Target, although the mechanism by which you map D_IDs and Ports to a 'Target' is substantantially virtual and different from Parallel SCSI. But the same issues apply as above, only more so. Inserting a device into an active causes all loop members to renegotiate their physical loop addresses (AL_PAs)- you're not guaranteed to re-acquire the one you had before. Thus your 'Target' can change while you're running. But the Qlogic driver handles this- at least while you're running by following the moved devices around based upon their WWN (see below on this). The point here I've been trying to make is that I can address and track both the parallel SCSI disk devices and the FC disk devices by parameters that are guaranteeed to be unique and that do *not* depend on the current physical bus address and do *not* depend on writing anything on the media. Disks (SCSI and FC) can be addressed by the Vital Product Data Serial # page. Fibre Channel devices can also be addressed by ther World Wide Name. Both are easy entities to get at (the Serial # stuff is already incorporated into CAM. The Qlogic driver already tracks WWNs- and just needs to propagate them upstream to be used). The namei actions in devfs could in fact parse a WWN or a VPD/Serial# name and do the right thing (look for it and find it on whichever SCSI bus or FC port it's one, whatever the current da instance number is). That'd be great. If you work with vinum, or wish to use disklabel on such volumes, then after you've imported things into vinum or used disklabel, you could also access such devices via the mechanisms you propose above. If you *don't* work with vinum, or don't/can't write disklabels, you still have a unique identifier by which to access the device that doesn't depend upon it's address at this moment. > I think this is what phk mentioned earlier about polling a list of drivers, > I'd just like to bring the concept out into the open more for discussion. 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. -matt 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?Pine.BSF.4.05.10007251730500.16927-100000>