[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-driver-discuss
Subject:    Re: [driver-discuss] fundamental question
From:       Dan Mick <dan.mick () sun ! com>
Date:       2007-12-19 20:48:39
Message-ID: 476983A7.2000006 () sun ! com
[Download RAW message or body]

Andrew Gallatin wrote:
> In the recent thread regarding the integration of the mfi driver,
> Garrett metioned how changing drivers for a particular piece of
> hardware nontrivial in Solaris:
> 
> "switching... /etc/path_to_inst and /etc/driver_aliases doesn't cope well"
> 
> Can somebody explain why we need them for modern devices which are
> easily identifiable via standard means (PCI, USB)?  Most other OSes
> dynamically probe their hardware and match drivers to devices based on
> probes or vendor/device lists compiled into drivers without need for
> these sorts of files.

Self-identifying hardware is sensed and identified by Solaris.  But coding 
that identification information into the driver is the wrong answer; that 
means that any new hardware must be addressed by a new driver, when at 
least some of the time, no actual driver operation needs changing, only the 
identification/binding.  With external text-file driver binding, as in 
Solaris, a device driver can be written to a generic spec, and, without 
editing the driver binary, it can be used for a new device by only editing 
the external files.

> As somebody who has done drivers on many other *nix clones for over a
> decade, I've always found the Solaris add_drv/rem_drv fragile and
> error prone.  Even more so, with the x86 boot-archive.  I can see how
> /etc/driver_aliases can be useful as an override, if the vendor/device
> list supplied by a driver is stale, but I'm afraid I don't see
> the point of using it as the general case.
> 
> I assume it must have something to do with having the correct drivers
> on-hand at boot time.  But there are other solutions for this in the
> form of building a cache of drivers needed to boot / and or preloading
> all drivers along with the kernel from the bootloader and ejecting
> unneeded drivers after boot.
> 
> Is this just a case of "it was always like this" and improving it
> would involve such a painful transition that it is not worth it?

While it may be that driver binding in Solaris is fragile, it's not because 
of the text-file binding info.  The problems usually arise from the intent 
to name driver nodes unambiguously by their physical path, and the 
constraints on naming the physical paths...and then the pervasion of those 
paths into disparate corners of the installed system.

The right way out of this is more 'logical' (as in the antonym of physical) 
naming, so that multiple slightly-different drivers can handle the same 
devices with only a change of binding.  For one, even moving to logical 
names itself brings up the upgrade problem, which we've never been willing 
to cross and say "sorry, you have to install afresh"; for another, as 
Garrett points out, often there are constraints on the child-driver parts 
of the path (when device support, say, changes from using SATA in "legacy 
IDE" mode, with the IDE disk driver cmdk, to "native SATA" mode, which 
looks like SCSI, so uses the SCSI disk driver sd, all the paths change from
.../cmdk@m,n  to ..../sd@m,n).

I'm hoping that at some point the driver-naming players can touch base with 
the Caiman folks and see if there is a rework of the upgrade-naming process 
that can be accomplished, but it's one of those sorts of problems that 
takes four hours to completely state to a group of people.
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
[prev in list] [next in list] [prev in thread] [next in thread]