OSDev.org

Well, it's me again, with some networking stuff:

What would you do:

Implement dhcp inside the network stack so one merely issues a "config device eth0 with dhcp" et voila, so is it done?

or 'd you rather recommend implementing a client thing which opens the necessary udp connections with the network stack and issues the necessary dhcp packets and does the post processing of received/not received dhcp packets (i.e. configuring iface or timing out)?

I'd appreciate your input

stay safe

ps: anyway, ere I'm about to implement dhcp, I have to get the udp layer up and going.

that depends on how you have your "network stack" ... i suppose if you have something like a "network server" process in your microkernel, it could very well handle ICMP and DHCP request/replies aswel as establishing new TCP connections and the like, then letting app play with connections once they're open.

A fun thing too would be to have "regular" packets directly handled by a thin library in client apps and odd things such as fragmented packets handled by the network service

Well... from an abstract POV, you either configure your network by hand, or let DHCP handle the configuration (partially or in whole).

"Configure by hand" sounds like editing a configuration file somewhere, doesn't it? (Or using a GUI frontend for doing so, you get my drift.)

Thus, the job of a DHCP client would be to edit (part or all of) the configuration file for the user, no?

Put that way, I don't think DHCP should be part of the network stack. Especially not if you're aiming for a lean design, as many networks will not use DHCP at all and could well do without the additional code.

And you'd reduce "critical code size", i.e. reduce the footprint of the network driver and reducing the probability of kernel-space errors.

IMHO, by someone who didn't even get near network code in his OS design.

Thanks for your replies, first of all.

I'm torn between the two approaches, know ya?

I want the interface configuring stuff to be rather simple. It should be like "ifconfig eth0 dhcp" and the network service (or the dhcp client) are provided with one according message and do the grunt work. Besides, it can also be "ifconfig eth0 192.168.0.20 255.25.255.0". I don't mind.

The basic idea is to hide most of the dirty stuff away. One can submit dirty stuff (extended parameters) alongside with ifconfig, socket et al, but one needn't to. In the wake of this, a graphical interface 'd merely issue the same calls to the network service as ifup,ifdown,ifconfig,ifstat would do.

Good. in case of a parameter "dhcp" I can as well have the config tool/command send a massage to a dhcp daemon in order to get the work done.

So, it is as usual a question of design and preference.

@Solar: It wouldn't be a kernel level error, but a system critic service 'd crap out, and that's a pain too. Micro Kernel, you know?

stay safe. I'm still rambling in /dev/brain

I would create three similar kernel modules, one using configuration scripts for the user to set (in whatever form) that simply hardcodes the addresses, one that does a full DHCP probe to figure out a valid IP address and one that uses ARP to guess one. This way, if you don't want a given function, leave out the (binary) module and you'll only increase the code by the interface-overhead. You won't keep any code loaded except for that which you want.