Hi Paul, >Sorry for the delay getting back to you, just got back from a week on >the playa lighting up dust storms with 2.4 and 5.8ghz wifi... :-) > ;-)
>> The reason I'm not really enthusiastic about this idea is that it adds a >> new dependency between sylinux, initrd and the etc package and also adds >> extra complexity to the linuxrc script. Something that I like to avoid as >> much as possible, because, for example, makes a change to a different >> kernel more difficult. > >Not really, or not as I understand it. It's looking at /proc/cmdline, >which is going to have the console port specified on it if a serial >console is chosen, unless someone makes source code changes to the >kernel or is running a non x86 kernel, neither of which are B-U worries >until the cross compilation environment works. :-) As far as I can >tell, there is no dependency on initrd, or syslinux at all. I would do >the same thing running grub or any other kind of boot loader. > What I mean is that a setting in the bootloader is parsed via linuxrc in the initrd to change a file in the etc package. With changing to a different kernel I mean from linuxrc/initrd to initramfs. >If you're going to actually publish and maintain hardware specific >configdb's, then what I'm proposing is not necessary. However, I've >become a big fan of having code just "do the right thing" when the right >thing is fairly obvious and considered this in the same vein as my >runtime patch to figure out that the keyboard controller wasn't present. I'm also a big of just do the right thing, but in the case of your kernel patch the solution was a lot cleaner and more generic. For example ttyS2 is not taken into account, which also needs a change in /etc/securetty. > Just a year ago you were compiling (or not, as the case was) special >kernels for the WRAP unit when all we needed was a one line test in the >kernel to support a runtime fix. The serial console stuff is currently >the one thing getting in the way of just copying the .lrp files over and >having them run. > >> An advantage of using some hardware specific configdb packages is that you >> can also set some other standard options, like selecting the right modules >> in /etc/modules, some network options and comment out the normal ttys. > >I was going to ask you what configdb things you would do for hardware >specific changes besides fixing inittab. Frankly, a HW specific >distribution with pre-populated moddb's wouldn't be awful. A few things that could be done in a HW specific configdb/moddb in the case of a WRAP f.e. is setting the serial console, disabling normal consoles, selecting the wd1100 module with the right parameters and the correct NIC module. Eric ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
