Dear Marcel Moolenaar, In message <018c5018-f1ce-4e30-9239-93c118cff...@mac.com> you wrote: > > It seems to me that these questions stem from an assumption > about how applications are written. That is, I always interpret
This is actually correct. The basic assumption I make, and request others to make too, is that we are working on a boot loader. If you compare finctionality with other boot loaders you realize quickly that we are stretching this concept pretty far - but there are certain limits. Things like more complex network protocols simply have no place in a boot loader. If you need something like that, then forget the API for standalone applications and boot an OS instead. It's much faster to develop, and much more flexible. > these questions as an inquiry into the use of an API so as to > argue about how an API is used, rather than how the API should > behave. Personally, I don't think this is the right approach > when discussing an API, because it the API comes with an assumed > use case. There is an assumed use case: things simple enough to fit into a boot loader. > As to the porting issues you were asking about: the FreeBSD boot > loader runs in many environments: PC BIOS, EFI, Open Firmware, > U-Boot, ARC (obsolete), etc. Which of these environments provide an API as you are asking for here? > As for the number of buffers: we need 1 for ARP. A small one I > might add. However, BOOTP/DHCP also needs a buffer. That's one > more. TFTP needs a buffer. etc, etc... Um... do these have to be separate buffers? Or would a single shared buffer be sufficient, too? We already have code in U-Boot that performs ARP, and BOOTP/DHCP, and TFTP. Why don't you use that code, instead of only the low-level primitives like packet receive? [Note that I am _not_ trying to just ask provocant questions. I'm really trying to understand your problem.] > The question as to how many buffers we need cannot really be > answered without digressing in "why don't you restructure your > code so that you only need 1". It all depends on how code is > organized, designed, modularized or combined. In the case of > the FreeBSD loader we a few places to change. This does not > include all the non-open features that people have added to the > loader. I must admit that I'm not too eager to add complexity to code that can be simple for U-Boot's own needs just to support some "non-open features" ... > The U-Boot APIs were intended and designed to work with any > application. More to the point: they we designed, implemented ...with any application running in the context and the restrictions of a boot loader. There has never been any intention to provide a runtime environment for complex things like an OS. > Ok, there's bug. Or at least a scenario that wasn't really > thought about or considered. The pivotal application, key > in designing and implementing the APIs, shows that the API > in U-Boot can hang. [The hang being caused by the reception > of a packet that is larger than the buffer the application > provides]. There are 2 simple fixed that would fix the API: > 1) just drop the packet. 2) return a truncated packet. Agreed. Both will change the behaviour of the current, common network code. Mike asked if there is any risk involved with such a change, and if we not better used a new function for this purpose. > However, I'm currently in a discussion that suggests that > the application should use bigger buffers. That strikes me > as odd, because by intend and design the API was to support > the application without requiring it to use bigger buffers. We're not talking about design of the API, but about changes to the U-Boot core network code. > Put differently: by requiring the application to use bigger > buffers, the API ipso-facto stops supporting the one app > it was designed to support. Is this a good way to fix an > otherwise minor problem? Hm... needing to change the core just to satisfy the needs of a single user with exotic requirements is something I don't decide quickly. At minimum I want to understand the need for the change, and be sure that it has no negative impact on other users of the same code. > To conclude: > I'm happy with an API change, whether it's dropping the > packet or returning a truncated one. Personally I favor > the truncation, because we're dealing with raw packets > and the application is expected to make sure it received > a proper packet to begin with. > > Changing the semantics of the API and require all > applications to allocate a bigger buffer to handle this > is not a solution in my opinion. You see just your use case, I try to see the whole U-Boot project. >From my point of view your requirement is not a change of the API to standalone applications, but a change to core functionality on behalf of a single user with exotic requirements. > In any case: the final verdict is with the U-Boot community. > I stated my case and look forward to the resolution so that > I can assess the consequences to me, FreeBSD, as well as my > employer (in reverse order of importance :-) Should this list impress me? It doesn't. Frankly, I don't care. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There's no future in time travel. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
