Re: User vs. Kernel (was: To be smug, or not to be smug, that is the
Steven Roberts (strobert@ata-sd.com)
Thu, 21 Jan 1999 16:46:59 -0800
"Albert D. Cahalan" wrote:
> Steven Roberts writes:
> > I personally like blocking system calls. They fit in far better
> > for the application model I use. We have multiple threads,
> > and it is easier to block. We in fact don't use the non blocking
> > I/O calls in win32 because it is easier for us at least to use
> > blocking ones. Yes, async IO can be nice for certain things, but
> > saying blocking system calls are a bad idea is crap.
>
> Don't tell me you _like_ interrupted system calls...
>
> Threads change everything. How would you like a new thread
> whenever a signal arrives? That could be an alternate fix.
I guess I'm not sure what you mean by an interuppted system call then.
in what cases will a read for example get interupted?
I think I must be missing something (it's probably obvious, but I've
been staring at way too much windows code today).
> >> If someone with great vision and design skills wants to create a
> >> new API for Linux, we should seriously consider such a proposal.
>
> > I think this kind of boils down to user vs. kernel API issues.
> > why not great this all new wonderful API set in a user space lib?
>
> Ha, ha, ha. NO.
>
> As a prototype, maybe. It would be an extraordinary kludge.
> It would have all the crappyness of user-space threads and worse.
>
> > I really like that the
> > kernel API in linux is small compared to the kernel API in win32. I
> > quite a bit about the win32 API, but the most important thing I know, is
> > that it is a big ugly mess, and I don't think linux should head in that
> > direction.
> No, the native NT kernel API is very simple. (it is not Win32)
That's why I said win32... most apps have to target 95/98/NT these
days, so using the native kernel API isn't practical (it also
isn't documented worth a damn -- best docs I have seen are from the
reverse engineering work from the sys internal's folks and the like)
>
> > I still like the old principle, of if you can do it in user space, then
> > do it in user space.
>
> How about "do it in the best place" instead? Often that place is
> a library, but don't get religious about it.
>
> In this case, the kernel API itself could use some adjustments.
> Emulating that in userspace is a sick joke.
Yes, if it does prove that it would be best in the kernel, then so be
it.
the best place principle is a good one, but I think if it is a tie
between user
and kernel, we should go user.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/