Mark Post wrote:
And would be different from how everything else is done, driving up costs, generating complaints ("Why is this different from my other systems? That's stupid.")I don't particularly care for using an initrd myself, but I'm not going to try to argue with the folks that put things together for shipping.
Actually, there are a lot of platforms using monolithic - or rather - non initrd systems - so the 'how everything is done' is not particularly .. hmm.. convincing ! Having all essential drivers required to load a root fs isn't something that is so uncommon ! The requirement to have an initrd is based solely on the diversity of storage device drivers required of distributed platforms - something that clearly doesn't apply to IBM System z ! There is a boatload of Linux kernel based systems that do not rely upon an initrd - and consequently - that have all the required drivers to load a root fs embedded. Basically, the requirement for an initrd was generated by 'distributed' systems.. Where you can stick in brand XXX variant ZZZ HBA.. but on IBM System z.. you can't do that ! And even more... Even if you were allowed to, it would have to follow either the Principle of Operations/OEMI channel specs/3990 CU specs or QDIO SCSI.. basically.. you have 3 drivers ! (ok.. FBA, CKD, ECKD, and FCP SCSI.. But that's still 3 since basic CKD isn't even supported!) The 'ability' to have an init ram disk (which is a good thing), doesn't necessarily means it is appropriate to use it very time ! (again, not saying this to you ! you already proved you *KNOW* this is true !). I'm failing to see where : - 'a kernel that works every time' "drives up costs" compared to : - 'a kernel that works if configured right and all necessary steps have been taken to ensure proper operations and you didn't forget something and you didn't mess up.. and don't forget to mkinitrd/zipl !' As far as the 'complaint generation', most of the complaint are driven by experience, not implementation. Most of the people do not *CARE* whether a driver is linked with the kernel or loaded dynamically.. but they will complain if it doesn't work (and you have to tell them that you *first* have to run mkinitrd followed by zipl to have their change working - wink-wink/nudge-nudge.. ok.. I've driven may nail far enough on this one..[1]) And if people complaint that they *DO* want to use an initrd.. Then DO let them do that.. That's the beauty of being *ABLE* to use an initrd.. you can - but you don't HAVE TO (and you definitely want to be able to use an initrd when dealing with a rescue system or an install system). And if people *REALLY* want an initrd (because that's what they read on an airline magazine) Then let them have it.. but have it set to a dummy init which simply simply does the pivotroot() and exec() the init available on the root fs (with a possible escape root for rescue). As far as I know, actually, the *CONTRARY* may be a killer marketing argument : With a distributed system, you have to worry about drivers.. with Linux on IBM System z : Nope.. Everything is there.. Don't worry about drivers.. Don't worry about funky initrds !.. It's all ready to run ! --Ivan [1] Again.. not a personal rant towards you Mark.. I'm relating this to the mainframe sysprog population.. *THEY* are no longer used to have to regen the system when adding storage.. This is something they would have done 15 years ago (VM/XA SP2.1 was probably the last as far as VM is concerned).. But they've been taught these are the ages gone by.. And have grown comfortable with the fact.. and all of a sudden, they're being told.. no.. you have to regen an initialization portion of the kernel and re-write the IPL record because you added a volume .. Sense the confusion ? ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
smime.p7s
Description: S/MIME Cryptographic Signature
