Eric Van Hensbergen <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: > > > There are two major uses of a console. > > - Status reporting (primarily for bootup) > > - Control by a trusted operator. > > > This is my thought exactly. The only hairy part comes during your > kernel boot-up when it asks you to manually fsck the drive (or other > such similar circumstances). There has to be some concept of being > able to attatch to the root console to enable you to perform such > operations. This is something lacking in the current proposed kernel > solution (and in our connectionless solution). > > There are certainly such instances in conventional BIOSes where you > get prompted for a resonse (configuration changes, alternate boot > environments, etc.) -- of course these could easily be handled through > extended DHCP, so perhaps there is no reason for interactive control > in the BIOS.
For debugging in a trusted enviroment these are simple things to implement. When you can't fully trust everything it is a significant issue. And in most production, as opposed to debugging enviroments there is a trust issue. For things like how should I fix this filesystem problem in general I say that calls for a sshd that starts up very early, that redirects the console messages. In a fully trusted debugging environment accepting raw packets as a stream of console characters is easy enough and gets the job done. Very rarely is there enough trust to implement that though. With late connections there is another feature that must be implemented to be useful. Keeping a buffer and printing the last couple of lines or at least the last N characters that were printed. So when you connect you don't get the dreaded blank screen problem. > > Specifics: > > 1) Network Address > > There is very little standardization right now, there may never > > be so an implementation should be able to select a mac address, > > and a ip address at compile time. > > I would suggest a multicast ip and the corresponding multicast > > mac address be used. As it allows any client on your local network > > to receive the packet. This is flexibility with the switch doing > > the work instead of the client. > > > > > Restricting it to MAC addresses should be sufficient. This allows > unicast, multicast, or broadcast (configurable at compile time or DHCP > time). This is the approach we have been using. When you add an extra ip/udp header you need to compile in some ip addresses as well. But if you aren't doing ip/udp it shouldn't be an issue. I am willing to consider using DHCP, or ARP but I will have to see some strong arguments for using it. One of the things I like to debug this way is why isn't DHCP working.... I simply don't see the need, for dynamic configuration. An extra header for filters is one thing, needing to configure it is something I don't want. But I guess we are pretty much in agreement here as you think an extra IP header is just extra useless junk. > > 2) Packet encapsulation > > Everything beyond raw string data is simply a convinience to make > > the data easier for an client to pick up. So ip and udp headers > > look like a good choice. Very simple and small to add. But make > > it possible to pick up the packet easily. And are the natural > > canidates so multiple implementations will work together by > > accident. > > > I'm not so sure on this end. I guess it depends on your network > environment, but we are able to always monitor on the same subnet as > the machines - so raw ethernet seems like a better solution. We don't > have to worry about retransmission, windows, yadda, yadda, yadda -- it > keeps everything dirt simple - which is very advantageous both in the > BIOS and dealing with situations where your IP stack may not be > entirely coherent. If raw packets are good enough I don't have a problem. I see encapsulating things in a udp packet as just a convinience feature. I am willing to go with whatever works best. > The other issue is that you essentially need to > have a correct IP configuration to make it work. I patched Ingo's > console into my kernel and was having trouble because it was trying to > start before my kernel had DHCPed, so it bailed. I think that is an implementation issue. You can do transmission as if you are a DHCP client and it should work. > Now that problem is > circumventable, but it does show a point of failure. Ethernet has no > such point of failure. As long as your ethernet card is working you > can transmit packets, end of story...it keeps things nice and simple. > Reception is very easy at an application level by just using > PF_PACKET, I think my catcher client is all of 50 lines of code. Nice. Then I may not worry about it as much. If raw ethernet is good enough I'm certainly in favor of it. I guess a different packet type is as good as a udp port for filtering. Though it isn't quite as well understodd. > I think the best approach would be to allow both options - either raw > ethernet or UDP/IP. Agreed. After there is some wide spread experience we can set some sane defaults, but util then making it configurable is good. > > This is all compatible with Ingo's suggested kernel interface, and > > can > > easily implemented elsewhere. > > So thinking this through I'm on board with the concept, and even > > willing to put some small amount of work into implementing it. > > Suggest? Comments? > > > I'll clean up our code this weekend (and/or Monday) and post necessary > snippets, its a fairly trivial amount of code (for just raw ethernet) > and it could probably be easily augments to do IP/UDP. > > The question is, where to implement it? Wouldn't etherboot be the > best place to have the ethernet console for the BIOS? It should be implemented where ever is convinient/needed, just like serial console support. - linuxbios - etherboot - linux - plan9 Eric
