On Fri, Jun 17, 2011 at 13:53, Masami Hiramatsu <masami.hiramatsu.pt@xxxxxxxxxxx> wrote: > (2011/06/17 8:04), Kay Sievers wrote: >> I don't think that solves the problem, no. We need _smart_ userspace >> with a debug/error message channel from the kernel to userspace that >> pops out _structured_ data. Userspace needs to index the data, and >> merge a lot of userspace information into it. > > If that is possible, I think it's so helpful. But most of driver > developers doesn't like that... They may tend to continue using > printk() debug/error notification. (actually I hope them to > use some notification API, like traceevent...) Sure they will add printk() for things, that's fine and should not change. There are things that can not and should not be formalized, and need a human to rad and fix it anyway. But it's also trivial to wire up the interesting debug/error information to some _sane_ channel at the same time, that does not produce for programmatic processing absolutely useless random and chaotic text dumps, but structured data for programs to consume. And right, it's very much like the problems tracing tries to solve. It's really time to leave the unix stone age behind us, and not to pimp up broken-by-design, or never designed, facilities. Storage management that needs this > Maybe, some kind of errors, like AER/MCE, easily move on to > such smarter system. But I doubt other device-specific errors > can do that too. There are so much specific kind of errors... > >> Adding just another single-name to the kernel just makes the >> much-too-dumb free-text printk() a bit more readable, but still sounds >> not like a solution. Pimping up syslog is not the solution to this >> problem, and it can't be solved in the kernel alone. > > I agree with you that the _smart_ error notifier can solve our > problem too. The lets start working on the real fix. We should stop papering over issues caused by pretty much useless free-text printk() strings. It just makes something totallydumb, a bit more pretty, introduces a lot diffferent problems by doing that, and has not the potential of solving the underlying problem properly. To me it sounds like a promise it can't deliver in reality. > However, we can't jump into it directly. > And just making printk() readable helps us A LOT! I'm not convinced. I think it only 'sounds' nice, but in reality, no 'single name' can be composed reliably. >> I don't think we can even solve 10% of the problems that way. It's >> just a hack that makes stuff a bit more pretty, but doesn't provide >> any reasonable solution to the problem. I doubt we can even make a >> simple use case out of it, what name to put into that field for a >> multipath setup. > > Good point! we have to consider multipath case in document. > Perhaps, we need a special naming rule in that case. I think > it can be solved if udev script is enough smart :-) I don't think that can be solved. You have the problem that all that needs to be available very early during boot to be useful, and I don't see how we can really have that policy information during that time. Kay -- 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
