rework HAL LInux coldplug to work with future kernel changes

Kay Sievers kay.sievers at vrfy.org
Wed Sep 20 10:55:48 PDT 2006


On Wed, 2006-09-20 at 08:21 -0700, Artem Kachitchkine wrote:
> > You can never tell for sure, what's physical and what not. If you run in
> > a virtualized environment, which is already pretty common today, the
> > kernel will not even tell you what's a real disk and what what isn't.
> > For your Firewire case, you could just guess, by matching on subsystem
> > == "ieee1394". But the only interesting property is "removable" or
> > "fixed" which is totally independent today, from the kind of bus it is
> > connected to.
> 
> This is all good in theory, but many people are aware of what they are 
> connecting. There are multiple connection points, but the device/system 
> boundary is what matters for most people. An IDE disk internally 
> connects to the IDE/FireWire bridge, put in an enclosure, connects to a 
> FireWire port, which internally connects to a FireWire/PCI bridge and so 
> on - but from a person's perspective it's a FireWire disk. It has a 
> FireWire logo on it and the matching port on the system has the logo. 
> And I want my GNOME disk icon to have the same logo.
> 
> It is responsibility of the system software to evaluate reliability of 
> the information about physical properties. The fact that in some cases 
> it _cannot_ reliably determine this, doesn't mean it should hide this 
> information when it _can_. VMWare gets out of its way to emulate an IDE 
> CDROM - it walks like a duck, fine, it's a duck. I don't see how 
> environments _designed_ to lie about physical properties should affect 
> our thinking about environments that don't lie.

What are you trying to tell here? I'm just for not calling it "bus", but
"subsystem", and remove the word "physical" from the properties, that's
all. I don't see any problem to match on subsystem=="ide", if you insist
making assumptions about the type of device with such properties. I
don't really see the point though, and HAL should not try do do stuff
that can never be correct.

Kay



More information about the hal mailing list