login
Header Space

 
 

Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Jean Delvare <khali@...>
Cc: Geert Uytterhoeven <geert@...>, Alessandro Zummo <a.zummo@...>, Ralf Baechle <ralf@...>, Thomas Gleixner <tglx@...>, Andrew Morton <akpm@...>, <rtc-linux@...>, <i2c@...>, <linux-mips@...>, <linux-kernel@...>, David Brownell <david-b@...>
Date: Friday, May 9, 2008 - 3:36 pm

Hi Jean,


 Well, these are not pieces of code and serve a different purpose, don't
they?


 Well, that is not a technical argument.  It is a fact of life, sure, but
it does not necessarily mean it is right, but perhaps that nobody has
really thought about it.


 Hmm, why to have little ambiguity, when you can have none?  We do not
rely on crippled filesystems, so we do not have to save characters in file
names -- we keep them reasonably short anyway.  I say there is no
technical advantage in having duplicate file names throughout the tree
(please name one if I am wrong) and there are advantages -- however small,
but still -- in keeping file names unique.  Therefore the gain from
converting the existing file names may not justify the effort required,
but it does not mean new additions may not take the gain into account?


 Human's perception is limited -- GDB's `info frame' is probably already
overloaded with information, so adding the path to the source file in
question will not make it any better.


 I think it is actually the reverse -- the bigger a project is, the easier
to get lost within. ;-)  With small programs it is easier to maintain,
while with bigger ones it is really where it pays off.


 I don't think this practice has been architected and see above for
justification why it may not necessarily be the cleverest idea. :-)

  Maciej
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Tue May 6, 8:40 pm)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Geert Uytterhoeven, (Wed May 7, 3:37 am)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Wed May 7, 5:25 pm)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Fri May 9, 3:36 pm)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Wed May 7, 5:13 pm)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Thu May 8, 7:10 pm)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Fri May 9, 4:27 pm)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Fri May 9, 9:43 pm)
Re: [RFC][PATCH 2/4] RTC: SWARM I2C board initialization, Maciej W. Rozycki, (Thu May 8, 6:43 pm)
speck-geostationary