Heh - this list has been dead so long I didn't notice that Thunderbird wasn't automatically showing new messages! :) Anyway, back to recent topics... If you want to boot from a HD, I wrote this little HOWTO a long time ago: http://www.wallman.org.uk/richard/elks/hd_install.html It did work for 0.83, with later versions YMMV. I'm not sure if my patches for selecting the root device actually made it into the main repository before the project slept, but I've still got the files here. Failing that, there's a bit of kernel hackery to stop it asking for root floppies. If there's someone with CVS commit access, I'll check my patches and resubmit. One thing I have been working on (on and off) for a while is 'User-Mode ELKS'. See the User-Mode Linux homepage[1] for details, and imagine the same for ELKS. This would certainly make writing and testing user-space tools a lot less painful. The two things that I always thought held this project back were: 1) Reliance on the BCC compiler, and 2) A very x86 PC-centric hardware assumption Point 1 is a bit of a problem - there is a lot of BCC-targeted code in there, and I've been struggling to get it working with GCC. Once it works with GCC, there's plenty of cross-compiling options for other platforms. I'm not saying that BCC should be dropped completely, just that GCC support would be nice. Anything less than 386 use BCC, anything equal or better use GCC. As for point 2, this is a real killer with regards to the E in ELKS. Personally, I'd like to see everything as an option, and have config-time options to specify driver parameters - two examples would be serial ports and the RAM map. I'd like the option to enter the port addresses and IRQs into the config file and skip autodetection, or leave it blank and use autodetection - for an embedded system, the hardware spec is known in advance, and saving a couple of seconds on boot times would be nice. With regards to the RAM map, an embedded system may have non-contiguous RAM blocks or some other weird setup, and an option to either autodetect or specify RAM blocks would be nice. This wouldn't affect ELKS running on old PCs, but would allow it to run on non-standard hardware. :) There's also quite a lot of embedded assembly in the code, which would make porting to other architectures a little difficult. Maybe have ARCH=x86pc, ARCH=x86generic, ARCH=sibo, ARCH=usermode, etc... Once these two restrictions are relaxed, I was going to start a 'Hardware for ELKS Linux Platform' project (HELP) - reference hardware designs and ELKS kernel config files for hardware hackers as well. This would certainly be of interest to both CS and EE university departments. One thing that did occur to me is that an ELKS system could sit entirely in on-CPU cache with modern processors - how fast would that be! What can I bring to the project? A bit of everything, but sadly not an awful lot of time (I have a 5 week old son who takes up a lot time!) In fact, in the time it's taken me to write this email I've had to stop to give him a bath and make a bottle for him! I can program in C, hold my own in assembly, do websites and documentation, and in the future hopefully get some hardware working. Jack of all trades, etc... Anyway, time for bed - I've got a 3am feed to prepare for. :S [1] http://user-mode-linux.sourceforge.net/ -- Richard Wallman Microsoft Windows - Where would you like your passwords to go today? - To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
