Date: Sat, 27 Mar 2004 10:11:26 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Nik Clayton <nik@freebsd.org> Cc: arch@freebsd.org Subject: Re: Where should devctl notifications be sent from? Message-ID: <21268.1080378686@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 27 Mar 2004 08:55:37 GMT." <20040327085537.GC33016@clan.nothing-going-on.org>
index | next in thread | previous in thread | raw e-mail
In message <20040327085537.GC33016@clan.nothing-going-on.org>, Nik Clayton writ es: >It looks like there are several places where the devctl_queue_data() and >related calls could be placed: > > firewire(4) -- when the device is plugged in > fwohci(4) -- when the interface arrives > sbp(4) -- when it's recognised as a mass storage device > geom(4) -- when geom creates the device (/dev/da2 (and da2s2) in my > case). Robert Watson has a patch that implements this. > devfs -- specifically, in make_dev(9) and destroy_dev(9) > >The limited research that I've done suggests that the most generic place >to put this code is inside make_dev(9) and destroy_dev(9). But this >seems so trivial that I can't believe no one else hasn't done the work, >so I figure there's probably something important that I'm missing. Hehe, this is far from a trivial question :-) The one question I would like you to answer is: How do you know it is the right iPod before you stuff it with you backup ? The problem is, more or less, that the higher up (ie: lower on your list) in the kernel you get, the more information you have lost. Devctl today is working on the newbus view of hardware, and there we have already lost most of the info that could help you make that decision. For disk devices GEOM has mechanisms for querying for out of band data like serial numbers, but nothing really uses this mechanism yet. I think that removable disks, as a class, is a sufficiently important that we probably should give them VIP treatment. I think this can be done equally well at GEOM and DEVFS levels, and DEVFS might catch other currently uncaught devices for us as well. So, it's not an answer to your question, but at least it narrows down the doubt a bit. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21268.1080378686>