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.
> 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.
> 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. 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. 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.
I think the best approach would be to allow both options - either raw
ethernet or UDP/IP.
>
> 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?
-eric
