[U-Boot-Users] [RFD] Consistent debugging output structure

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

Hi, 

I would like to discuss the current state of the u-boot debug output
code. Nearly every C file in the source tree implements it's own way of
outputting debug messages during development, and most of them do it by
using Yet Another #ifdef Desert (TM). 

Therfore, I would like to propose that we add a generic header file,
something like this: 

----------8<----------
#ifndef __UDEBUG_H
#define __UDEBUG_H

#if (DEBUG > 2 )
#define DBG_PRINTF3(fmt,args...) printf(fmt ,##args)
#define DBG_PUTS3(args...) puts(args)
#else
#define DBG_PRINTF3(fmt,args...)
#define DBG_PUTS3(args...)
#endif

#if (DEBUG > 1)
#define DBG_PRINTF2(fmt,args...) printf(fmt ,##args)
#define DBG_PUTS2(args...) puts(args)
#else
#define DBG_PRINTF2(fmt,args...)
#define DBG_PUTS2(args...)
#endif

#ifdef DEBUG
#define DBG_PRINTF(fmt,args...) printf(fmt ,##args)
#define DBG_PUTS(args...) puts(args)
#else
#define DBG_PRINTF(fmt,args...)
#define DBG_PUTS(args...)
#endif

#endif /* __UDEBUG_H */
---------->8----------

which could be included by every file that wants to make debug outputs;
it just had to define the DEBUG level before it #includes udebug.h. 

The transition could be done incrementally - it just has to be
documented somewhere that this is the preferred method. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

On Wed, Mar 19, 2003 at 07:32:07PM +0100, Robert Schwebel wrote:
> I would like to discuss the current state of the u-boot debug output
> code. Nearly every C file in the source tree implements it's own way
> of outputting debug messages during development, and most of them do
> it by using Yet Another #ifdef Desert (TM). 

I've already discussed that with Wolfgang (no idea why the mail needed
several days to hit the list) and he wants to use the debug() macro
instead, which is ok for me. 

What we don't agree on is if we need several debug levels. What do the
others think? For more complex drivers like the ethernet ones this is
really useful. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Vladimir Gurevich]

Hello Robert,

Robert Schwebel wrote:
> What we don't agree on is if we need several debug levels. What do the
> others think? For more complex drivers like the ethernet ones this is
> really useful. 

Based on how I normally do this sort of debugging in my drivers
these are the questions I ask myself:

1) Do I want dynamic debugging levels (i.e. the ones I can choose
    at runtime). If the answer is "yes" then debug level should be
    stored in a variable, otherwise it should be a macro.

2) How big the performance hit will be and how important it is?
    If I don't mind performance hit, then I have dynamic debugging
    with default level "0". Otherwise I use a macro and let the
    compiler optimize it out.

About debug levels. Normally I use bits to specify what do I want
to debug instead of relying on "greater than" comparisons. This way
I have much greater flexibility and can enable only the debug outputs
I really need right now.

Here what it normally translates to in C:
===========================================================
/*
  *  Debug levels for my driver (say, vag01)
  */
enum {
     DEBUG_VAG01_INIT    = 0x00000001, /* Initialization sequence   */
     DEBUG_VAG01_INTR    = 0x00000002, /* Interrupt handling        */
     DEBUG_VAG01_API     = 0x00000004, /* Standard API calls (open, */
                                       /* close, read, write, etc.  */
     DEBUG_VAG01_RX      = 0x00000008, /* Receive data path         */
     DEBUG_VAG01_TX      = 0x00000010, /* Transmit data path        */
     DEBUG_VAG01_RX_DATA = 0x00000014, /* Dump received data        */
     DEBUG_VAG01_TX_DATA = 0x00000018, /* Dumt transmit data        */
     DEBUG_VAG01_RELOCK  = 0x00000020, /* Debug relock thread       */
};
/*
  * Compile-time configuration parameters for the driver vag01
  */
#define DEBUG_VAG01           /* No debugging compiled in if it */
                               /* is not defined                 */

#define DEBUG_VAG01_DEFAULT 0 /* The initial debug level. Can be */
                               /* (DEBUG_VAG01_INTR | DEBUG_VAG01_API) 
*/
                               /* or something like that */

/*
  * Here is the debug print
  */
#if defined (DEBUG_VAG01)
#define debug(level, fmt, args...)    \
     do {                              \
        if (debug_vag01 & (level)) {   \
            printf(fmt , ##args);      \
        }                              \
     } while (0)
#else
#define debug(level, fmt, args...)
#endif

/*
  * Here is the debug level variable
  */
static __u32 debug_vag01 = DEBUG_VAG01_DEFAULT;

===============================================================

Some other comments:
   1) I use an anonymous enum to define debug levels. This way it
      becomes easier to change them from gdb by typing:

      (gdb) set debug_vag01|=(DEBUG_VAG01_TX | DEBUG_VAG01_RX)

   2) When I am doing that for Linux I also provide /proc interface
      to change this debug level dynamically (plus a "debug" module
      parameter, or course)

   3) In case of multiple devices of the same type (not quite important
      for u-boot) you can move the debug_level variable into the driver
      instance structure

   4) Again, probably not important for u-boot, but important for a
      Linux-based system: it becomes very easy to add a registration
      API so that each debuggable component could register its levels
      with a centralized debug command. Then you can easily control
      debug levels by typing
          debug <component> <level>
          undebug <component> <level>
          show debug
          show debug <component>
      pretty much the same like Cisco IOS does.

   5) Checking the debug level upsets the cache and this might become
      important in the performance critical parts. Then I use a couple
      more compile-time flags to remove just this debug from the
      production-level code.

Just my 2 cents.

Best regards,
Vladimir Gurevich

[U-Boot-Users] [RFD] Consistent debugging output structure

[Vladimir Gurevich]

Oops, sorry for the typo:

Vladimir Gurevich wrote:
> enum {
>     DEBUG_VAG01_INIT    = 0x00000001, /* Initialization sequence   */
>     DEBUG_VAG01_INTR    = 0x00000002, /* Interrupt handling        */
>     DEBUG_VAG01_API     = 0x00000004, /* Standard API calls (open, */
>                                       /* close, read, write, etc.  */
>     DEBUG_VAG01_RX      = 0x00000008, /* Receive data path         */
>     DEBUG_VAG01_TX      = 0x00000010, /* Transmit data path        */
>     DEBUG_VAG01_RX_DATA = 0x00000014, /* Dump received data        */
>     DEBUG_VAG01_TX_DATA = 0x00000018, /* Dumt transmit data        */
>     DEBUG_VAG01_RELOCK  = 0x00000020, /* Debug relock thread       */
> };

Should be

enum {
     DEBUG_VAG01_INIT    = 0x00000001, /* Initialization sequence   */
     DEBUG_VAG01_INTR    = 0x00000002, /* Interrupt handling        */
     DEBUG_VAG01_API     = 0x00000004, /* Standard API calls (open, */
                                       /* close, read, write, etc.  */
     DEBUG_VAG01_RX      = 0x00000008, /* Receive data path         */
     DEBUG_VAG01_TX      = 0x00000010, /* Transmit data path        */
     DEBUG_VAG01_RX_DATA = 0x00000020, /* Dump received data        */
     DEBUG_VAG01_TX_DATA = 0x00000040, /* Dump transmit data        */
     DEBUG_VAG01_RELOCK  = 0x00000080, /* Debug relock thread       */
};

Regards,
Vladimir

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <20030322102847.GF28544@pengutronix.de> you wrote:
> On Wed, Mar 19, 2003 at 07:32:07PM +0100, Robert Schwebel wrote:
> > I would like to discuss the current state of the u-boot debug output
> > code. Nearly every C file in the source tree implements it's own way
> > of outputting debug messages during development, and most of them do
> > it by using Yet Another #ifdef Desert (TM). 
> 
> I've already discussed that with Wolfgang (no idea why the mail needed
> several days to hit the list) and he wants to use the debug() macro
> instead, which is ok for me. 
> 
> What we don't agree on is if we need several debug levels. What do the
> others think? For more complex drivers like the ethernet ones this is
> really useful. 

I think that several  debug  levels  built  into  a  debug  mechanism
(usually  combined  with  some logging features) makes a lot of sense
for an application-type system or product.  It  is  useful  when  the
software  structure  is  pretty  much  constant,  and when there is a
separation between "developers" and "users".

I want the U-Boot design to keep  an  eye  on  efficiency  and  small
memory footprint. Several debug levels may seem useful here and there
(in  which case they are trivial to add based on the existing debug()
macro), but in general they are just overkill.

Those parts where debug printout is really needed are  too  much  CPU
and board dependend anyway.


Yes, I agree, new code should not introduce it's own  "#ifdef  DEBUG"
stuff any more, but use debug() instead - but this is IMHO one of the
"nice to have" issues, not a really important issue.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I know engineers. They love to change things.             - Dr. McCoy

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

On Sun, Mar 23, 2003 at 03:32:24PM +0100, Wolfgang Denk wrote:
> I want the U-Boot design to keep  an  eye  on  efficiency  and  small
> memory footprint. Several debug levels may seem useful here and there
> (in  which case they are trivial to add based on the existing debug()
> macro), but in general they are just overkill.

- There are currently several places in the code (for example network
  drivers) where people have already done that and added their own
  implementations, so there seems to be a need. 

- I've not seen an argument _against_ a central, unified implementation. 

- It does not change performance or memory footprint in any way, because
  if it is switched off the debug code is not in the binary. Why do you
  think that useful unified code wich is optimized away may be overkill?
  I don't understand your argumentation. 

> Those parts where debug printout is really needed are  too  much  CPU
> and board dependend anyway.

Like network drivers...? 

> Yes, I agree, new code should not introduce it's own  "#ifdef  DEBUG"
> stuff any more, but use debug() instead - but this is IMHO one of the
> "nice to have" issues, not a really important issue.

If you see it that way NOTHING is an important issue, because u-boot
somehow works. I think that we agree that the code is a huge mess in
quite a lot of places, and having a unified debug mechanism would make
it better. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Holger Schurig]

> Yes, I agree, new code should not introduce it's own  "#ifdef  DEBUG"
> stuff any more, but use debug() instead - but this is IMHO one of the
> "nice to have" issues, not a really important issue.

In Linux, Linus is sometimes making changes to Linux that breaks other 
drivers. He does so by intent, e.g. by renaming types/variables where the 
structure changed. He does also accept janitorial patches. If somebody then 
is angry and says "Change XYZ broke my driver" he simply says "So fix it".

In U-Boot, I have the perception that things happen differently. You say "new 
code should do it like this", but without changing the existing code. I guess 
you go this route so that you don't break code for some boards you don't 
have. I assume that over time this approach will lead to various ways on how 
to do things, maybe to old cruft lying around.

So, basically it's a tradeoff. Have clean code and pain. Or have not-so-clean 
code, possible with overhead, and less pain.

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <20030324062929.GO28544@pengutronix.de> you wrote:
>
> > Yes, I agree, new code should not introduce it's own  "#ifdef  DEBUG"
> > stuff any more, but use debug() instead - but this is IMHO one of the
> > "nice to have" issues, not a really important issue.
> 
> If you see it that way NOTHING is an important issue, because u-boot

Things that effect stability or  robustness  are  vitally  important,
also things that make it easier to port U-Boot to new hardware etc.

I don't think it is a good idea to globally change many source  files
just  to make the code more beautiful. U-Boot is running fine on some
100+ boards now, it has been seen in the Space Station, and  is  used
as  production firmware for quite a lot of commercial boards. For me,
stability and robustness are more important  that  worrying  about  a
"#ifdef DEBUG" when "debug()" could have been used.

> somehow works. I think that we agree that the code is a huge mess in
> quite a lot of places, and having a unified debug mechanism would make
> it better. 

We already do have such a "unified"  debug  mechanism,  and  you  are
welcome to use it in your code, and everybody else, too. Use it where
it fits. Where it doesn't fit, use something else.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The man on tops walks a lonely street;  the  "chain"  of  command  is
often a noose.

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

On Mon, Mar 24, 2003 at 09:14:22AM +0100, Wolfgang Denk wrote:
> We already do have such a "unified"  debug  mechanism,  and  you  are
> welcome to use it in your code, and everybody else, too. Use it where
> it fits. Where it doesn't fit, use something else.

You avoid my question. Would you accept a debug2() debug3() patch, which
does no harm to any of your 100+ boards or the space station? Nobody
wants to change the whole code at once, but when I work on new code I
would like to do it _right_ instead of adding more mess to the existing
one.  

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

On Mon, Mar 24, 2003 at 08:44:21AM +0100, Holger Schurig wrote:
> In Linux, Linus is sometimes making changes to Linux that breaks other 
> drivers. He does so by intent, e.g. by renaming types/variables where the 
> structure changed. He does also accept janitorial patches. If somebody then 
> is angry and says "Change XYZ broke my driver" he simply says "So fix it".
> 
> In U-Boot, I have the perception that things happen differently. You say "new 
> code should do it like this", but without changing the existing code. I guess 
> you go this route so that you don't break code for some boards you don't 
> have. I assume that over time this approach will lead to various ways on how 
> to do things, maybe to old cruft lying around.
> 
> So, basically it's a tradeoff. Have clean code and pain. Or have not-so-clean 
> code, possible with overhead, and less pain.

Ack. U-Boot has reached a size where it is simply impossible for one or
two maintainers to make sure that _all_ ports remain working while
things progress. I want to repeat the suggestion I've made before: make
a list on the web site with something like "board/maintainer/test-date".
Who wants to have a version which is actually working has to start with
the latest tested u-boot version and probably see what is working and
what fails, which has to be ported up. Then speed up the release cycle
so that people at least don't have to rely on CVS versions but on
"unstable" releases.

I don't say that all that quality inspection is wrong, but otherwhise
the code will never been cleaned up. And I suppose we are in an unstable
release cycle!

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <200303240844.21463.h.schurig@mn-logistik.de> you wrote:
>
> In U-Boot, I have the perception that things happen differently. You say "new 

Right. U-Boot is less complex, it has different targets, and I'm  not
Linus ;-)

> So, basically it's a tradeoff. Have clean code and pain. Or have not-so-clean 
> code, possible with overhead, and less pain.

Right.

To make this clear: I am not against cleaning up code in general. BUt
I don;t think it is something that is so urgent that we should do  it
now  in all source files. The disadvantages (like dropping stability)
are IMHO bigger than the advantages.

Let's perform such cleanup whenever we notice it in existing  coe  we
touch for other reasons (i. e. functional changes).


I would also  like  to  point  out  the  there  are  cases  where  an
alternative approach perfectly makes sense:

Compare:

----------------------------------------------------
#ifdef DEBUG
	for (i=0; i<N; ++i) {
		int val;
		
		val = some_function(arguments);

		printf ("Value = %d\n", val);
	}
#endif
----------------------------------------------------


against:

----------------------------------------------------
	for (i=0; i<N; ++i) { 
		some_type val;
		
		val = some_function(arguments);

		debug ("Value = %d\n", (int)val); 
	}
----------------------------------------------------


Functionally both  are  equivalent.  (2)  uses  the  "cleaner"  debug
interface. Yet I prefer (1) here, which is much clearer to me.

Also, are you really, really sure that the call to  "some_function()"
will   be  optimized  out  in  the  second  case?  For  all  possible
combinations of "some_type" and "some_function()"?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <20030324082308.GA28544@pengutronix.de> you wrote:
> On Mon, Mar 24, 2003 at 09:14:22AM +0100, Wolfgang Denk wrote:
> > We already do have such a "unified"  debug  mechanism,  and  you  are
> > welcome to use it in your code, and everybody else, too. Use it where
> > it fits. Where it doesn't fit, use something else.
> 
> You avoid my question. Would you accept a debug2() debug3() patch, which

I have answered this question before. I see no need for such a  patch
in  the  common  code. You can easily implement it using the existing
debug() macro if you feel you need it in your own code.

I will reject such a patch if it globally effects all boards and  all
common code.


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Totally illogical, there was no chance.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <20030324083612.GB28544@pengutronix.de> you wrote:
>
> Ack. U-Boot has reached a size where it is simply impossible for one or
> two maintainers to make sure that _all_ ports remain working while

This is not a querstion of size, but primarily of available hardware.

But the effect is the same, of course.

> what fails, which has to be ported up. Then speed up the release cycle
> so that people at least don't have to rely on CVS versions but on
> "unstable" releases.

What's the difference? It's  just  a  change  of  name.  Each  tagged
version in the CVS represents an "unstable" release.

> I don't say that all that quality inspection is wrong, but otherwhise
> the code will never been cleaned up. And I suppose we are in an unstable
> release cycle!

It is unstable for some boards / architectures only.  My  idea  of  a
development  tree  is  that  I  try  to  avoid  breaking working code
whenever possible.


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Defaults are wonderful, just like fire.
                  - Larry Wall in <1996Mar6.004121.27890@netlabs.com>

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

On Mon, Mar 24, 2003 at 09:52:23AM +0100, Wolfgang Denk wrote:
> I have answered this question before. I see no need for such a  patch
> in  the  common  code. You can easily implement it using the existing
> debug() macro if you feel you need it in your own code.
> 
> I will reject such a patch if it globally effects all boards and  all
> common code.

How could it affect other implementations if, additionally to the
existing debug() function, debug2() and debug3() are added? Sorry, but I
don't understand your arguments. I've never said that I wanted to change
the whole code at once.  

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

On Mon, Mar 24, 2003 at 09:50:02AM +0100, Wolfgang Denk wrote:
> To make this clear: I am not against cleaning up code in general. BUt
> I don;t think it is something that is so urgent that we should do  it
> now  in all source files. The disadvantages (like dropping stability)
> are IMHO bigger than the advantages.

When will you start then, if not during an "unstable" u-boot series? 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Robert Schwebel]

On Mon, Mar 24, 2003 at 09:57:22AM +0100, Wolfgang Denk wrote:
> What's the difference? It's  just  a  change  of  name.  Each  tagged
> version in the CVS represents an "unstable" release.

You can point people to that version and tell them "This board worked
with version x.y.z. Either take that version or look if it does still
work with CVS.". And that without teaching users how to work with cvs
internals. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <20030324085922.GD28544@pengutronix.de> you wrote:
>
> > I will reject such a patch if it globally effects all boards and  all
> > common code.
> 
> How could it affect other implementations if, additionally to the
> existing debug() function, debug2() and debug3() are added? Sorry, but I

Ummm... if the definition is not used anywhere (except  in  your  own
new code), it just adds to the overhead without cleaning up anything.

> don't understand your arguments. I've never said that I wanted to change
> the whole code at once.  

Ummm... then I did not understand at all what you want.

If you just want to add some extended debugging  mechanism  for  your
own local code, please go on. But keep it local, then.


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I have often regretted my speech, never my silence.

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <20030324090047.GE28544@pengutronix.de> you wrote:
>
> > To make this clear: I am not against cleaning up code in general. BUt
> > I don;t think it is something that is so urgent that we should do  it
> > now  in all source files. The disadvantages (like dropping stability)
> > are IMHO bigger than the advantages.
> 
> When will you start then, if not during an "unstable" u-boot series? 

I will _always_ resist a general cleanup just for having  cleaned  up
code.  I  want  to keed a readable history of changes for the code. I
will not generally break this just to make the code better readable.

Whenever a functional change or bug fix is required to a source file,
I am willing to perform such a cleanup.

But no generic/global cleanup patches, please.


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Our management frequently gets lost in thought.   That's because it's
unfamiliar territory.

[U-Boot-Users] [RFD] Consistent debugging output structure

[Wolfgang Denk]

In message <20030324090309.GF28544@pengutronix.de> you wrote:
>
> You can point people to that version and tell them "This board worked
> with version x.y.z. Either take that version or look if it does still
> work with CVS.". And that without teaching users how to work with cvs
> internals. 

You now can tell people to use the version tagged LABEL_YYY_MM_DD_hhmm.
I don't see much difference.  And adding a "-rTAG" option to a checkout
command is not really CVS internals, is it?


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Making files is easy under  the  UNIX  operating  system.  Therefore,
users  tend  to  create  numerous  files  using large amounts of file
space. It has been said that the only standard thing about  all  UNIX
systems  is  the  message-of-the-day  telling users to clean up their
files.                            -- System V.2 administrator's guide