[OCF] ocf-shellfuncs standardization - Comments? Objections?

[Nick Stoughton]

I need to start making some progress on this ... I've waited a month!

On Thu, 2005-07-07 at 22:51, Alan Robertson wrote:
> Nick Stoughton wrote:
> >>Nick:  If you would consider withdrawing or modifying your bugzilla to 
> >>the LSB until we finalize our own discussion, that would be much 
> >>appreciated.
> > 
> > It turns out that my bugzilla comment was a dup of an earlier one, and
> > has been closed as a duplicate. However, the timeline has this as a
> > defect to be fixed in release 3.1 (to be published late September 2005
> > if all goes according to schedule).
> > ...
> It worked for fprintf :-)
Well, how exactly??? fprintf says "The fprintf() function shall place
output on the named output stream." And defines how streams work. All
I'm doing here is the same thing.

> 
> But, more seriously...
> 
> _Which_ are you trying to test?  The base LSB capabilities?  An LSB init 
> script?  A vendor's overall init process?  Are you trying to test them 
> in an boot environment?  Standalone?  Are you going allow adding things 
> to the messages printed?  Or do they have to be printed exactly as they 
> are (the message, the whole message, and nothing but the message)?
> 
If there was a test (there isn't one today), it would be of the init
functions. My proposal said that the format of the message was
unspecified...so no, they don't have to be printed in any given form.
Anything could be added to or taken away from the message (for example,
it might be translated into a foreign language).

> The point of the API is that they are redirected to a place where they 
> are visible (if requested) during the boot sequence.
> 
Exactly. That is precisely what my proposal said. The message is sent to
stdout in an unspecified format. This can be redirected, etc as required
by the init script, or by the infrastructure that calls init scripts.

> That's the requirement - which is driven by the intended purpose.  If 
> you left out "(if requested)" for example, then the implementation would 
> have no option for a less-scary boot sequence like basically all Linux 
> vendors do now.  Similar things happen if you add much beyond what the 
> purpose requires.
> 
I don't quite follow this ...


Just for clarity, here is exactly what I'm proposing the LSB does:

Change "The log_xxx_msg function shall cause the system to print a xxx
message." to "The log_xxx_msg function shall cause the system to print a
xxx message to the standard output. The format of this message is
unspecified."

-- 
Nick Stoughton      USENIX/FSG Standards Liaison
nick at usenix.org     (510) 388 1413