| |||||||||||||
Application-friendly kernel interfacesApplication-friendly kernel interfacesPosted Mar 29, 2007 8:21 UTC (Thu) by ms (subscriber, #41272)In reply to: Application-friendly kernel interfaces by orospakr Parent article: Application-friendly kernel interfaces
I think this is a great idea. This allows for greater decoupling between glibc and the Linux kernel and is, IMHO, the proper abstraction. Plus, if the authors of the kernel interfaces are subsequently charged with writing liblinux entries then there could well be cases where the authors rather return to the drawing board and rethink the kernel interface if it's just too damn hard to use from userspace.
(Log in to post comments)
liblinux Posted Mar 29, 2007 11:30 UTC (Thu) by hummassa (subscriber, #307) [Link] This would also permit the kernel devs to further experiment in yankingfunctionality out of the kernel... things that _could_ be done in userspace without performance penalties _should_ be done in userspace :-) linux + liblinux would be maintained from the same source -- so they would always be in sync -- and this would be really great.
liblinux Posted Mar 29, 2007 11:54 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link] Indeed, it really sounds like a great idea. This way, systems like GTK/glibc and Qt/kdelibs could link to this library or even only use it when available to speed some things up, while using workarounds on other OS'es like the BSD's, solaris, mac OS X etc.
Really? Posted Mar 29, 2007 22:21 UTC (Thu) by man_ls (subscriber, #15091) [Link] Do you really think it is a great idea? Pardon for my lack of knowledge about kernel development, but why is it so great? I mean, you design a hard-to-use interface, then write your own code which presents a friendly interface to userspace -- and you write it in userspace. Well, why not present a friendly interface in the kernel in the first place?Is it just because kernel->userspace interfaces are set in stone and have to be maintained forever? For that would feel a bit like medieval astronomers -- weaving layer over layer of epicycles so that their spheres would match the real planet trajectories. Here we would have a kernel interface set in stone, then some library code -- which once people use it would again be set in stone, only to add a new glue layer... again and again. Waiting a few iterations might be a better course of action, and I gather from LWN that it is often taken by kernel devs. If the purpose of this scheme is to have a more powerful interface, I much prefer our editor's suggestion: A separate library for developers trying to do obscure and advanced things with the kernel might be the right solution.I have seen too many complex interfaces that nobody uses because they are so complex, and everyone uses the simplified version. Better start simple, and then add complexity as needed.
Really? Posted Mar 30, 2007 1:16 UTC (Fri) by cpeterso (guest, #305) [Link] Is it just because kernel->userspace interfaces are set in stone and have to be maintained forever? For that would feel a bit like medieval astronomers -- weaving layer over layer of epicycles so that their spheres would match the real planet trajectories. Here we would have a kernel interface set in stone, then some library code -- which once people use it would again be set in stone, only to add a new glue layer... again and again. Waiting a few iterations might be a better course of action, and I gather from LWN that it is often taken by kernel devs.I think the kernel API can change, so user programs should use the "friendly" userspace library APIs.
Really? Posted Mar 30, 2007 5:40 UTC (Fri) by IkeTo (subscriber, #2122) [Link] > I mean, you design a hard-to-use interface, then write your own code which> presents a friendly interface to userspace -- and you write it in > userspace. Well, why not present a friendly interface in the kernel in the > first place?
Perhaps the whole hugetlb thing tells one of the possible reasons. The original /dev/hshm interface is actually more general than the /dev/hugetlb interface: it allows multiple processes unrelated in ancestry to share the same piece of huge page. It is probably preferable for the kernel API to use only the general interface rather than having to implement both, since every time the interface change it needs to have a "global search" for libraries/applications using the interface, and leave enough time for those libraries/applications to change (if Linus does not say "no" to the change right away). So it might be preferable to implement just the general interface, hoping that it will never change at all; and have another library "cast" it to various different forms that are "more friendly" forms like the hugetlb interface. What unclear to me is actually why one would expect that the new library could be exempted from the global search if it needs to be changed.
I think instead of a general liblinux, we should be contented with the tested solutions of, e.g., pthread (futex) and libfam (dnotify): if the functionality fits well into a general audience, the easier interface is implemented in libc, and if it is not, the easier interface is implemented in a functionality specific library. That way, when the generic interface is changed, the kernel developers have fewer places to search for direct users of them; and the specific interface is usable (and thus relied upon) by a more narrow set of end-user applications.
liblinux Posted Apr 6, 2007 1:06 UTC (Fri) by slamb (guest, #1070) [Link] I'm not sure about "would always be in sync". If you require that, people who have multiple kernels on their box would need some mechanism such that the correct liblinux for whatever kernel they happened to boot is dynamically loaded. Seems possible, but it's a step beyond "maintained from the same source".This is one of those areas where the BSDs have an easier time. They do "make world", and it's just inconceivable that an actual end user would mix'n'match kernel and userspace from different versions of FreeBSD. They got away with things like top assuming layout of kernel structures and accessing /dev/kmem for a long time. On Linux, that sort of mutt system is considered normal, so stuff has to be carefully versioned.
|
|||||||||||||