| |||||||||||||
Some upcoming sysfs enhancementsSome upcoming sysfs enhancementsPosted Mar 9, 2006 10:10 UTC (Thu) by nix (subscriber, #2304)In reply to: Some upcoming sysfs enhancements by kirkengaard Parent article: Some upcoming sysfs enhancements
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 :(
(Log in to post comments)
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
|
|||||||||||||