| |||||||||||||
Some upcoming sysfs enhancementsSome upcoming sysfs enhancementsPosted Mar 9, 2006 5:11 UTC (Thu) by kirkengaard (subscriber, #15022)Parent article: Some upcoming sysfs enhancements
One is tempted to suggest that the head-bashing that is happening over stable API in 2.6, with the good ideas about sysfs, relayfs, and other kernel-to-userspace representations may make a good 2.7 issue, to have a major rework of the good ideas without the "keep it stable" kluges. Eventually it'll hit critical mass; if that's it, then I look forward to 2.8 in terms of userspace system diagnostic capabilities.
Of course, I could be altogether worng. :)
(Log in to post comments)
Some upcoming sysfs enhancements Posted Mar 9, 2006 10:10 UTC (Thu) by nix (subscriber, #2304) [Link] Certainly I can't see many apps using sysfs if it keeps changing at this rate. There've been major changes (to the behaviour / layout, not just the contents) in virtially every kernel release to date.
One problem is that the sysfs tree is big enough (and pins enough memory) that piling lots of compatibility stuff in there is not an option :(
Some upcoming sysfs enhancements Posted Mar 9, 2006 14:52 UTC (Thu) by bronson (subscriber, #4806) [Link] Oh my god! The number of ioctls is getting way out of hand and the calls are totally inconsistent! It's a mess! I know, let's put most of the information in /proc. What could be simpler than just opening a file?
(4 years later)
Oh my god! The number of files in /proc is way out of hand and who knows what each file is supposed to contain?? It keeps changing. It's a mess! Hey I know, let's make another filesystem, like proc, but only one value per file. That will clean things right up.
(4 years later)
Oh my god! The number of files in /sys is way out of hand. I know *what* the file is supposed to contain but I have no idea where it is! It keeps moving. It's a mess! Hey, I know. Erm... Userspace compatibility library?
Some upcoming sysfs enhancements Posted Apr 20, 2006 11:21 UTC (Thu) by mic.f (guest, #30242) [Link] What's the point in designing an API that changes every month ? This is simply useless..but kernel hackers feel so comfortable with this "perfect approach" to kernel development and they continue to reply on criticism with "use distros kernels" but how the fuck I am supposed to write a sysfs-capable app if redhat, debian, suse and every other linux distro have unaligned versions ?
IMO the reality is: developers are happy with the idea that they can change everything everytime in every place of the code BUT people and external developers and the COMMUNITY needs some sort of plan in doing this...Why larger projects do have roadmaps and the linux kernel cant ? Seems like it's because "hey im a kernel hax0r im cool lemme mess around in the code when that exciting speed enanching patch comes in or whatever new thing im happy to put in is ready, i dont care if it will break here and there"
MAYBE "ioctl -> proc -> sysfs -> NEXT_BIG_THING" could have been avoided with DESIGN DECISIONS and some planning and some middle term thinking of new kernel features..
If this is impossible to think by kernel developers, maybe a simple 6-months stable releases cycle (like gnome & co) should align distros and the community on the same kernels.. at least for some months
Some upcoming sysfs enhancements Posted Mar 9, 2006 21:31 UTC (Thu) by iabervon (subscriber, #722) [Link] Having 2.7/2.8 wouldn't be a considered a sufficiently good excuse to break userspace like that. Version number is more about whether the internal function is similar; if you enable the right options, your Linux 1.2.13 programs should still work.
Now, it's possible that the "stable API" discussion will lead to having the kernel source include libraries linked from userspace programs and run in usermode. At that point, a lot of code can be moved out of the kernel executable and supervisor mode while not having a stable API between it and devices (it would provide a stable API to programs, of course, but compatibility stuff is relatively easy there), and a bunch of stuff currently distributed separately could be moved into the kernel tree (alsalib, e.g.). If this happens, maybe the version number should change from 2.6.x to 3.x, because it's a kind of major organizational change, and it would be good to acknowledge that the development methodology is really different from the 2.n period.
|
|||||||||||||