On Sat, 2011-06-18 at 21:54 -0400, Kyle Moffett wrote: > On Fri, Jun 17, 2011 at 10:27, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 2011-06-17 at 01:04 +0200, Kay Sievers wrote: > >> >> We need many names, and we need all of them from the very beginning, > >> >> and they should not change during device lifetime unless the device > >> >> state changes. > >> > > >> > So that's actually an argument for leaving the links, surely? We can > >> > have many inbound links, but the kernel can only print one name in > >> > messages, which would be the preferred name that was currently set. > >> > >> I really question any concept of _the_ name. My take on it: It will > >> never work in reality. > > > > OK, so lets take the common example: a desktop with three disks and an > > enclosure with three slots and labels "fred", "jim", and "betty". > > > > The desired outcome is that whenever the user manipulates those devices > > he uses a name related to the label, so whenever dmesg flags a problem, > > it says sd betty: device offline or something. Whenever he mounts, he > > mounts by /dev/disk/by-preferred/betty (or whatever the current udev > > vernacular is). Whenever smartmon says there's an over temp problem. it > > says that fred has it; cat /proc/partitions shows how fred, jim and > > betty are partitioned and so on. > > Hm... > > So there's already all this work going into an event-tracing framework, > and most of the interesting device errors are getting converted to use > functions such as "dev_err()" and the like. > > Perhaps the kernel needs a "log" event? You could add a basic unique-id > allocator (64-bit integer) and give each device or other interesting object a > unique "tag". A generic printk without a "tag" field would automatically > get tag 0. > > There would be another few special events generated to make it possible > to uniquely map tags to device-model objects (or filesystems or whatever) > long after the fact, including enough information to determine the parent > device or other key attributes. > > Then all of the dev_dbg() would automatically generate the necessary > trace events tagged by device, with the log-level and "string" as the > payload. > > Suddenly you can monitor a device (and optionally all of its parents or > children) for "interesting kernel events", even if that particular driver > is still doing all of its logging with "primitive" dev_err() printks. > > Since it's tagged by device you can just install a modified "klogd" that > cooperates with udev to log events with information about exactly > which device-model node it applies to. You can even have that > program generate dbus messages, so your desktop environment > can complain that the kernel has reported filesystem errors on that > thumbdrive you just plugged in, but that the media itself seems to > be fine (no I/O errors). > > A future extension might be to allow trace-events to have a "fallback" > handler of sorts analogous to the way that audit messages are > currently handled. If a process is monitoring events and has a filter > which matches the event then it will be handled by that process; > otherwise it will call the "fallback" handler and resort to a printk(). > > That would allow a more advanced driver to generate specific > status and error messages for consumption by monitoring software, > but still fall back to dmesg when the system is in single-user-mode > or the monitoring software dies, etc. > > Thoughts? It's been tried several times before. No-one who ever began this project found the commitment to finish it ... however, perhaps you'll be the first ... James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
