On 8/16/05, Paul Howarth <paul@xxxxxxxxxxxx> wrote: > Try using /etc/sysconfig/modules/hdparm.modules instead. Is /etc/sysconfig/modules mentioned anywhere outside of the rc.sysinit itself? I'm not seeing it mentioned in /usr/share/doc/initscripts-8.11.1/sysconfig.txt nor anything higher level that a novice admin would reach for. This was introduced in fc4 and was not shipped as part of fc3. I'm just wondering how exactly are admins suppose to be discovering these sorts of additions? Are admins really expected to be reading over the logic in rc.sysinit script with every iteration? The only reference I see to how to use this outside of rc.sysinit is a terse changelog line.. which doesn't indicate anything about the naming constraints for filenames nor anything with regard to when in the linear init process these files will be activated so an admin would still have to read rc.sysinit directly to figure out what to do and whether it fits their needs. <quote> /usr/share/doc/initscripts-8.11.1/ChangeLog: load user-defined module scripts from /etc/sysconfig/modules at boot </quote> Thats it.. thats the only reference I see on my system and its of course duplicated in the rpm package changelog. Now reading over rc.sysinit isn't particular difficult for an experienced unix administrator.. but a dare say that there is a significant segment of the userbase who are cutting their teeth on the experience of being an 'admin' while running fedora at home are going to be significantly confused when trying to read through rc.sysinit unless they are explicitly told that they need to learn full bash logic syntax before working with admin only level items on a fedora system. You need to know much less about bash scripting to write a short hdparm.modules file that just has the hdparm commands you need in it than it is to follow rc.sysinit. Making the modules file feature syntax only discoverable via rc.sysinit review seems backwards to me. I'm just asking to get a better feel of the learning curve expectations being set for people who are going to admin boxes. I'm not looking to expose this graphically so people can clicky-click their way through esoteric hardware setup.. I just want to make sure that there is a clear understanding as to what admins should "know" before touching the system and to make sure features are exposed in such a way that admins can start from that baseline amount of knowledge and work from that starting point with "reasonable" on-system documentation and references to additional documentation. I have a pretty good idea as to where the expectations lie for the casual user functionality and its clear there is a long term plan to get tools out for that audience that are commiserate with the learning curve expectations for casual users.. but I don't think there is any plan floating about on how to make it easier for a novice admin to work efficiently with the system...especially when new functionality is exposed. For new admin accessible features ( like the addition of sysconfig/modules/ ) that fall outside the casual user audience definition, I don't have any real sense as to what the consensous expectation on what admins need to do to discover new features and what they should do learn how to configure new features. Nor do I see an effort to identify baseline level(s) of knowledge assumed for "admins" when exposing a new feature. In this case it seems rather counterproductive to require an admin to read through the logic in rc.sysinit to discover that files need to be named /etc/sysconfig/modules/*.modules and be executable. The details need to be explained in /usr/share/doc/initscripts-X.Y at the very very least. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
