On Dec 17, 2007, at 9:17 AM, Rafal Jaworowski wrote:
- How is this really different from the existing jumptable stuff? It looks like it's just a different set of exported functions. Will the crufty old jumptable interface be removed at some point? Presumably, the new interface is superior, so it should be. Right?
Let me chime in for this, quickly, because we did try to use the jump table and it proved to be useless. As Rafal pointed out, the problem with using the jump table is that: 1) getting to the jump table requires that you know the layout of the global_data structure, because it's at the end. The layout of the structure is highly variable due to the optional fields. As such, in order to use the jump table, you need to configure the "client" program in the same way as U-Boot, just to make it work. This is especially frustrating if the client program itself has, inherently, no configurable options and you need it to run on a couple of flavors of boards that need slightly different U-Boot configurations. 2) The jump table itself is not fixed in that there are optional entries. On top of that, the jump table has no way to account for extensions or growth, because there's no function you can call that gives you a version or some sorts.
The first point can easily be fixed by putting the jump table first or at least at the head of the global_data structure. The second point can partially be fixed by making all entries non-optional and provide stubs in case a function has no implementation in a certain configuration. This however would be against the basic design philosophy of U-Boot, so would by itself raise concerns.
More importantly, the crux of the second point could not be addressed and that's typically where the problems arise going forward. In fact, we knew that we were going to run into problems, because the current jumptable did not have the interfaces we'd like to see and there were even ones we didn't need right from the start, but knew we'd want within a year. And, once this has become a known interface, who knows what people want to do with it?
The bottom line was that while the existing jump table would get us 80% of the way, getting that additional 20% would be impossible without doing exactly something along the lines of what Rafal did.
I fully realize that for developers who's focus is U-Boot, anything that runs on top of U-Boot and that wants something from U-Boot is a burden at times, but it is important to realize that U-Boot is most of the time nothing more than the first step towards a useful machine and that there can be more than 2 steps in getting on OS to run. The ability to make use of the (hardware) knowledge that U-Boot has, and at the same time its ability to abstract it for the next steps, is in my opinion just as important as having its own prompt.
Just my $0.02