Re: RFC: android logger feedback request
I have no problem leaving the logger driver in staging, but it seems that Tim is taking on the task to do the harder thing here, which probably would entail work on both sides, which as a openhandset alliance company member, he might have a change that someone like me might not :) I'd like to see it in staging. There is a general discussion going on about how such logging services should look (and indeed it goes back before Android bits), and it looks like a good way to proceed is going to be to play with the Android one - perhaps adding the fs model to it. So we need something and the Android interface at the very least is a prototype that has production proof of working. Alan -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
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. Do you want to load a 70K daemon and an initrd or burn about 1.5K on a kernel interface ? I'd rather burn 0K on the one we have today :) So say N when configuring 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 ? 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. 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. Alan -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
That's one extra process, not that much, right? About 150K or so way too much and its not robust. Fair enough. So, with this driver, would it make sense for the distros to switch over to using it instead of the above line in their initrd? Distros no - I doubt any normal PC distro would turn the facility on. Embedded - yes especially deeply embedded. Ok, I didn't realize it really was that big. libc page tables app page tables stacks (kernel and user) arguments/exec page buffers Yes - it soon adds up. Alan -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, 25 Aug 2010 11:16:47 -0700 Greg KH gre...@suse.de wrote: On Wed, Aug 25, 2010 at 07:14:37PM +0100, Alan Cox wrote: That's one extra process, not that much, right? About 150K or so way too much and its not robust. Fair enough. So, with this driver, would it make sense for the distros to switch over to using it instead of the above line in their initrd? Distros no - I doubt any normal PC distro would turn the facility on. Embedded - yes especially deeply embedded. So should this be dependent on CONFIG_EMBEDDED then? No objection to that -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
+static int tpk_write_room(struct tty_struct *tty)
+{
+ int ret = tpk_space;
+
+ /* allow char by char under max pressure */
+ if (tpk_space == 0)
+ tpk_space = 1;
That won't do what you think, the ldisc will keep seeing progress and
generate millions of 1 byte I/Os in a loop !
Otherwise looks excellent.
+ switch (cmd) {
+ /* Stop TIOCCONS */
+ case TIOCCONS:
+ return -EOPNOTSUPP;
And I'll fix this bit up to work properly in the core code.
With my devices.txt owner hat on I'll allocate the minor as you suggest
(and double check this causes no problems), with my tty hat on can you
send it to GregKH for merging into the tree.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
For correct flow control, i suppose current empty space of the real (final) printk buffer is needed. On the other hand my intermediate Console drivers have their own buffering so that doesn't really work. If you want to just avoid explosions then you don't need to be quite so clever in some logical manner. And the other would be to use ratelimit support to switch between max and zero in write_room answer and remove other retelimit response? Yes - except that a driver isn't permitted to reduce the write room space by more than bytes written. That is if you offer 512 bytes you can't offer 0 until 512 bytes have been written - hence the design of the pseudo code I posted in the previous message. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
I'm thinking to leave the ratelimit support in for the time being. I had
in mind cases, when someone does
cat /proc/kmsg dev/ttyprintk or
suppose the console is redirected to ttyprintk (which i would like to be
able to do from user program)
Console as in the printk sense would then loop.
If you are going to do the flow control you should probably do something
like
write_room()
{
if (!flow_controlled)
space = 8192;
return space;
}
write()
{
space -= len;
}
then your flow control will behave properly and slow down users rather
than losing data (except stuff sent without blocking)
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I manage/modify console baud rates from userspace?
Is there some other way to modify the baud rate of the console device from userspace once I figure out the right one? It would definitely be less than ideal since we'd lose all the boot output, except what we can get from dmesg _if_ the system boots, but it would be something. stty 57600 /dev/ttyS1 etc. The console baud rate and settings should behave exactly as any other serial port if set from user space. Any other thoughts or ideas? If you don't mind doing some small private kernel tweaks then I guess you could set the default console baud rate based on the dmi strings which would hopefully differ between the blade types. Alan -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] console logging detour via printk
while i was searching for effective logging of complete console output
produced by the kernel and user phase of the boot process, it turned out
that only kernel messages imho get systematically cached and stored into
log files (if needed). All userspace processes are on their own to use
syslog, which is fine, but there are also many console messages
reporting the boot status via init scripts, I came across the
bootlogd daemo, which handles the job of redirecting console output into
a log file, but i find it problematic to use especialy, when using
initial ram disk image.
So you want to patch the kernel because you can't work out how to do this
in userspace ? The distributions seem to have no problem doing this in
user space that I can see. It doesn't seem to be a hard user space
problem, and there are a ton of things you want to do with this sort of
stuff (like network logging) that you can't do in kernel space.
--- a_linux-2.6.33.3/drivers/char/vt.c
+++ b_linux-2.6.33.3/drivers/char/vt.c
@@ -2696,6 +2696,16 @@ static int con_write(struct tty_struct *tty, const
unsigned char *buf, int count
{
int retval;
+#ifdef CONFIG_VT_CONSOLE_DETOUR
+ if (console_detour) {
+ int idx = vt_console_driver.index - 1;
+
+ if ((idx = 0) (idx == tty-index)) {
+ console_printk_detour(buf, count);
+ return count;
+ }
+ }
+#endif
This requires you go around hacking up each device which is not a good
idea and becomes rapidly unmaintainable.
I suspect what you actually need for such logging might be to write a
very simple tty driver whose write method is implemented as printk. That
works in the general case and doesn't require hacking up the code
everywhere else.
However given your init stuff can trivially use openpty to set up a logged
console I am not sure I see the point in doing this in kernel in the
first place.
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] console logging detour via printk
The distros have no problem logging complete console output into log files or over the network, because they simply do not do it at least for the initrd part of the boot process (i'd be glad, if i'm wrong). I'd have to double check - but its trivial to move the log if so. I suspect what you actually need for such logging might be to write a very simple tty driver whose write method is implemented as printk. That works in the general case and doesn't require hacking up the code everywhere else. Looks to me that some kernel code is welcome:)? I really don't see the point but if you must do it then doing it as its own driver would at least avoid making a mess in the rest of the kernel, at which point it becomes less of a problem However given your init stuff can trivially use openpty to set up a logged console I am not sure I see the point in doing this in kernel in the first place. As said above, how to bridge kernel boot start and logging daemon start-up without kernel help, especially when initrd is in the way? imho it would be too complicated. Put the logging start up in the initrd, its just a ramdisk its not special in any way at all. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27- Sending uevent from a driver
Or, maybe the userspace program can receive some sort of interrupt from the TTY device when it is ready for I/O. Perhaps there is another way to avoid continued polling? TIOCMIWAIT ioctl for modem signals, and just using poll/select() on the tty for I/O. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
Ah, that doesn't work, when you want to use the USB serial console _if_ there's a USB serial adapter plugged in, and a different (lower priority) console if it's not. I don't see the problem. If there is a lower priority console available then the kernel can use that anyway and clearly that would be the right thing to do. The case that wouldn't work perhaps is the 'no console present and a USB or firewire one might appear' - for that to work you'd need the queue to be smarter - or even the lowest priority console... Alan -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
Alright, I know you (Alan (Stern)) know about USB. I think someone else mentioned Firewire. What other hotpluggable buses do we need to worry about and how can we get them interested? In theory any console can be hot pluggable - PCI-X hotplug video cards, hotplug serial ports. In fact right now bad things occur if you hot-unplug consoles. 2.All devices have been probed If we exit for reason 2, it means that no such device is present, and we go on to the do the appropriate thing for that device class. USB has no notion of #2 really Yes, I think we absolutely exclude devices plugged in after boot. I think such usage, if it needs to be supported, can be handled with hot plugging. I'm a little squishy on whether we might to be able to hot plug USB consoles as I have a request to support this, but I think it's a separate issue from supporting hot pluggable boot devices and I'm not worrying about it now. This still assumes you can tell the difference, but USB in particular is rather like undergraduate students - they turn up when they feel like it at some point after they get kicked into life. I don't think that is a big problem because our bus model is basically that all devices are discovered asynchronously (increasingly so with Arjan's speed up patches). A console model therefore has to deal with console addition and removal being dynamic. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
+config PRINTK_CONSOLE_WAIT + int Default number of milliseconds to wait for console device + default 1000 Does this only delay init during a console-less bootup - or are there other later apps that might trigger the delay? The console proper needs to be event based not timeout hacks. Can we please fix this stuff properly ? To start with there is no reason that the USB console can't implement a maybe we have hardware, maybe I buffer 64K until it shows up behaviour and bind to hardware as and when USB serial devices get inserted. We do much of this for the VT drivers so we save messages before PCI and fb come up. The timeout wait proposed is also wrong I agree. Take a timestamp at the point we are ready to mount the root fs, any delays on root mount, console appearance etc should then be tested against this timestamp not as delays versus some undefined later event. Alan -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wait for console to become available, v3.2
failing to open it, why can't we make __tty_open() give you a dummy tty driver which is basically equivalent to /dev/null? And then 'replace' it with the real console driver if/when that later gets registered? The latter will be a high-caffeine job, but surely not impossible? This sounds like a good option. Don't confuse /dev/console and the console device in printk terms. The two are not the same thing and the latter is subject to stuff like redirection. thing, but it should be possible to just do something like static struct tty_driver console_driver; No - a console device can fail to open so you need to try the next one in that situation. Some platforms use this feature. Anybody want to try it? Just make it ignore any IO if there are no registered consoles. The patch shouldn't even be all that big, I suspect. It will work, but on its own it won't actually fix the problem people have, which is wanting to wait for a real console to appear. Extending it to sleep (if not O_NDELAY) and loop back through the list when the list changes would however do the trick, that or a tty device that buffers then spews into the real device when it appears. Definitely the right path, and we almost have every tty device in existance containing a struct tty_port, at which point it gets even cleaner. The printk() console needs to buffer up data and replay it but we already pretty much do what is needed even for vt consoles because the fb isn't ready before the first printk. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
I note that sed and printf and such are all susv3. I have an explicit test for 32 bit math in the script that cares, and this worked in Red Hat 9 circa 2003. If you are trying to do arbitary precision maths using standard posix tools just use dc. That way the standard is explicit about what you will get. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
What about deep call chains? The problem with the uptake of 4K stacks seems to be that is not reliably provable that it will work under all circumstances. On x86-32 with 8K stacks your IRQ paths share them so that is even harder to prove (not that you can prove any of them) and the bugs are more obscure and random. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
By your logic though, XFS on x86 should work fine with 4K stacks - many will attest that it does not and blows up due to stack issues. I have first hand experiences of things blowing up with deep call chains when using 4K stacks where 8K worked just fine on same workload. So there is definitely some other problem with 4K stacks. Nothing of the sort. If it blows up with a 4K stack it will almost certainly blow up with an 8K stack *eventually* - when a heavy stack usage coincides with a heavy stack using IRQ handler. You won't catch it in simple testing, you won't catch it in trivial simulation and it'll be incredibly hard to reproduce. Not the kind of bug you want in a production system really. IRQ stacks make things much more predictable. Alan -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
