Re: RFC: android logger feedback request

2011-12-23 Thread Alan Cox
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

Re: [PATCH] detour TTY driver - now ttyprintk

2010-08-25 Thread Alan Cox
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

Re: [PATCH] detour TTY driver - now ttyprintk

2010-08-25 Thread Alan Cox
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

Re: [PATCH] detour TTY driver - now ttyprintk

2010-08-25 Thread Alan Cox
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

Re: [PATCH] detour TTY driver - now ttyprintk

2010-08-24 Thread Alan Cox
No, it does cover that. You should be able to do that with a simple console redirection to /dev/kmsg What happened when you tried to do that? stty: standard input: Inappropriate ioctl for device It's value is twofold - formatting - tty ioctls work as they should on a console (eg vhangup)

Re: [PATCH] detour TTY driver - now ttyprintk

2010-08-24 Thread Alan Cox
- formatting Ick, we really want to format things from userspace here? Depends what you are trying to do. Put an embedded hat on 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 Do you want to

Re: [PATCH] detour TTY driver - now ttyprintk

2010-06-25 Thread Alan Cox
+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

Re: [PATCH] detour TTY driver - now ttyprintk

2010-06-22 Thread Alan Cox
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

Re: [PATCH] detour TTY driver - now ttyprintk

2010-06-21 Thread Alan Cox
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.

Re: Can I manage/modify console baud rates from userspace?

2010-05-03 Thread Alan Cox
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

Re: [PATCH] console logging detour via printk

2010-05-01 Thread Alan Cox
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

Re: [PATCH] console logging detour via printk

2010-05-01 Thread Alan Cox
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

Re: 2.6.27- Sending uevent from a driver

2009-07-02 Thread Alan Cox
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:

Re: Wait for console to become available, v3.2

2009-04-22 Thread Alan Cox
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

Re: Wait for console to become available, v3.2

2009-04-22 Thread Alan Cox
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

Re: Wait for console to become available, v3.2

2009-04-21 Thread Alan Cox
+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

Re: Wait for console to become available, v3.2

2009-04-21 Thread Alan Cox
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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

2009-01-04 Thread Alan Cox
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

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-27 Thread Alan Cox
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

Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

2008-08-27 Thread Alan Cox
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