On Wed, Aug 25, 2010 at 11:08:13AM +0100, Alan Cox wrote: > > > Do you want to be able to flip between a real debug interface and a > > > logging device on the same software set without risking changing behaviour > > > > I don't understand this point. > > A tty has a very specific set of behaviours simply by being a tty. Some > applications rely upon them so being able to flip between the two > interfaces is useful. Would that work for this driver in use as a console? > > Seriously, look at how Fedora 14 handles this, why can't you do the same > > for embedded systems all from userspace, no additional code needed > > anywhere. > > Its a whole set of extra processes and daemons and stuff, and > minimally uses something like 70K even if its very compact (8K stack, 40K+ > page tables, 16K of buffers, code, data) - oh and I forgot the fifo > buffering and pty cost - so its near 100K. 1.5K v 100K - for something > 1.5K of kernel code that anyone else can turn off and would be off by > default ? exec < /dev/console > /dev/kmsg 2>&1 That's one extra process, not that much, right? > On a lot of embedded systems you don't have all the stuff Fedora carts > around. No modules, initrds, magic front end processes, graphical startup > daemons etc, all of which work to produce that feature IFF you have pty > support in your kernel, and for the current code also glibc. It sounded like they had an initrd that they cared about here. > You also want errors to get out (or stored) even if there are crashes - > which the Fedora one is not very good at. To be fair in the Fedora world > its not a big deal to say 'Oh dear, boot with ....'. Embedded isn't the > same, and you want to capture the odd rare error reliably. again, the above exec line should work for what the embedded people want, right? thanks, greg k-h -- 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