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
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
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
+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
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
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
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
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:
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
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
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
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.
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
+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
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
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
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
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
18 matches
Mail list logo
