ron minnich rminnich@lanl.gov writes:
so, in the config file, we have something like:
extension pcbios extension vgabios extension elfboot
and the system linkes these in via src/extionsions/whatever.
They are each run in turn.
reasonable?
Not really.
I haven't seen the numbers on the dreaded size overhead. So that argument does not yet convince me. If I can fit a whole IP/UDP stack a network driver, and printk in 16K I have trouble seeing the problem.
Most of the things proposed so far are things I am primarily opposed to, at least except way out on the periphery. Callbacks are bad. Binary only code is bad. Maintenance would be a pain, and we have not even succeeded in doing a single stable release off of either of our public trees yet.
I would much rather see these things prototyped with something like Steve James bare metal tool kit. We can easily open another tree just for that up on sourceforge, like we did with the freebios2 tree.
And the biggest reason I don't want to go there is because simple things tend to be reliable. And complex things tend to broken. And the extension extension looks to allow a lot of needless complexity into LinuxBIOS.
Also the problems being solved with the extension mechanism are vary different from what is solved with the core of LinuxBIOS so there are very different evolutionary pressures. And there are a different group of people working on those problems, and the evolution happens at different rates.
I am not opposed to solving those problems, not even expediently. But I don't want a solution in the public tree that causes maintenance problems.
My mind can be changed, but I need to see a good reason to do this. The biggest piece of code everyone has been arguing for including, the code to run a vgabios option rom, simply doesn't work in a lot of cases, and unless I have overlooked something the reason it doesn't work in a lot of cases is a design flaw, it doesn't aim for complete pcbios compliance.
Eric