On Tue, 2009-11-17 at 07:45 -0800, Eric W. Biederman wrote: > Artem Bityutskiy <dedekind1@xxxxxxxxx> writes: > > > On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote: > >> 2009/11/17 Artem Bityutskiy <dedekind1@xxxxxxxxx>: > >> > Take a look at my mails where I describe different complications we have > >> > in our system. We really want to have an OOPS/panic + our environment > >> > stuff to go together, at once. This makes things so much simpler. > >> > > >> > Really, what is the problem providing this trivial panic-note > >> > capability, where user-space can give the kernel a small buffer, and ask > >> > the kernel to print this buffer at the oops/panic time. Very simple and > >> > elegant, and just solves the problem. > >> > > >> > Why perversions with time-stamps, separate storages are needed? > >> > > >> > IOW, you suggest a complicated approach, and demand explaining why we do > >> > not go for it. Simply because it is unnecessarily complex. > >> > >> I don't think it's a complicated approach we are talking of a system > >> log like syslog with a temporal information, nothing more. > > > > We need to store this information of NAND flash. Implementing logs on > > NAND flash is about handling bad blocks, choosing format of records, and > > may be even handling wear-levelling. This is not that simple. > > > > And then I have match oops to the userspace environment prints, using I > > guess timestamps, which is also about complications in userspace. > > > >> > This patch solves the problem gracefully, and I'd rather demand you to point what > >> > is the technical problem with the patches. > >> > > >> > >> Simply because I think that we should avoid to include in the kernel > >> things we can do in a simply way at user space level. > > > > If it is much easier to have in the kernel, then this argument does not > > work, IMHO. > > > >> I think this > >> patch is well done but it's one of the patches that are solutions "for > >> embedded only", but it's only my opinion. > > > > Also IMHO, but having embedded-only things is not bad at all. > > Why not use the kdump hook? If you handle a kernel panic that way > you get enhanced reliability and full user space support. All in a hook > that is already present and already works. For some reasons kdump does not work on ARM out of the box. We need to investigate this. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
