[U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet.

[Wolfgang Denk]

Dear Marcel Moolenaar,

In message <018C5018-F1CE-4E30-9239-93C118CFF386 at 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.