| |||||||||||||
Extended error reportingExtended error reportingPosted Feb 22, 2010 11:05 UTC (Mon) by nix (subscriber, #2304)In reply to: Extended error reporting by mjcoder Parent article: Extended error reporting
Find a way to do that without violating POSIX, adding a huge new layer of
non-POSIX infrastructure (which nobody will ever use for portable code), or replicating every single POSIX call (which all set errno) with some other call (which throws this kernel->userspace exception thing).
Now find a way to throw exceptions from the kernel into userspace without
(Log in to post comments)
Extended error reporting Posted Feb 22, 2010 11:22 UTC (Mon) by mjcoder (guest, #54432) [Link]
I'm not sure about it, but is POSIX compatibility required at kernel level - or is it enough to get POSIX compatibility at "libc" level?
Extended error reporting Posted Feb 22, 2010 13:46 UTC (Mon) by nix (subscriber, #2304) [Link]
What's the point of an extended error reporting interface if it's only
exposed to the libc? Of *course* applications will have to be able to see it.
Extended error reporting Posted Feb 24, 2010 11:25 UTC (Wed) by mjcoder (guest, #54432) [Link]
Just imagine: You would be able to have several subsystems (like POSIX with limited error information) on top of a stable feature rich kernel. I really like this idea. Something like Wine could be implemented as another subsystem ... or even BSD compatibility (if needed).
Extended error reporting Posted Feb 24, 2010 22:41 UTC (Wed) by nix (subscriber, #2304) [Link]
I'm just imagining what Al would say about the possibility of adding extra
personalities to the Linux kernel for something like this (personality() is what Linux uses for this sort of thing). I don't think I can invent elaborate enough ways of saying 'hell no'.
(Among other things, this would partition the space of processes *again*:
|
|||||||||||||