From: Jim G. <ga...@ll...> - 2001-02-22 01:10:48
|
On Wed, 21 Feb 2001, H. Peter Anvin wrote: > Jim Garlick wrote: > > > > Maybe I'm not explaining this clearly, but it's actually quite simple: > > > > wc -l *.c > > 395 ec.c # rewrite of minicom > > 789 elancon.c # protocol + elan interface > > 542 elantty.c # tty driver, both callout and "elancon" > > 1726 total > > > > That's not what I would consider simple, and that is with the > infrastructure of a full kernel underneath. Seriously, it's a pretty > absolute requirement that this can be implemented in assembly in a few > kilobytes, for a pre-booting system. Ah - here is where we differ, I am planning for LinuxBIOS so I always have the whole kernel underneath. Still, most of the above is tty support for a getty which you won't need in the pre-boot stage, and code to deal with the comms, which is a given you need anyway... The protocol support is only a tiny part. > Again, more complexity at the client. If you're willing to accept data > loss, which you obviously are, then why are you worried about "a single > point of failure"; note that the idea of the protocol is that the server > can be rebooted or even replaced, so you could keep a hot spare available > and switch it in place with a simple ifconfig command. OK, that would be good. On the single point of failure, losing a character here and there is less critical to me than losing the whole console system... On the other hand, if the protocol were robust enough to capture 512 nodes oopsing at once, that would be a plus :-) Jim |