[LinuxBIOS] patch: add arch-dependent lib

[ron minnich]

Per discussion on the list, we are adding an arch directory to
arch/x86, and putting a lib and other files in there we want to
include with #include <arch/foo.h>

Signed-off-by: Ronald G. Minnich

[Uwe Hermann]

On Mon, Jun 25, 2007 at 02:19:35PM -0700, ron minnich wrote:
> Per discussion on the list, we are adding an arch directory to
> arch/x86, and putting a lib and other files in there we want to
> include with #include <arch/foo.h>
>
> Signed-off-by: Ronald G. Minnich

NAK.
> Index: include/arch/x86/arch/lib.h
>
> --- include/arch/x86/arch/lib.h	(revision 0)
> +++ include/arch/x86/arch/lib.h	(revision 0)
> @@ -0,0 +1,23 @@
> +/*
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2 of the License, or
> (at your option) any later version.
> This program is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU General Public License for more details.
> You should have received a copy of the GNU General Public License
> along with this program; if not, write to the Free Software
> Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> */

Please use the common copyright header, with you as a copyright holder.

This header doesn't have the "part of LinuxBIOS" line and the copyright
holder.

Uwe.

[ron minnich]

try this one.

ron

[Uwe Hermann]

On Mon, Jun 25, 2007 at 02:59:51PM -0700, ron minnich wrote:
> try this one.

Better, thanks, but some more comments:
> arch library file
> inluded in include/lib.h
> Signed-off-by: Ronald G. Minnich
> Index: include/lib.h
>
> --- include/lib.h	(revision 364)
> +++ include/lib.h	(working copy)
> @@ -37,4 +37,5 @@
>  void ram_failure(const char *why);
>  void ram_initialize(int controllers, void *ctrl);
>
> +#include <arch/lib.h>
>  #endif /* LIB_H */

I think we handle this differently currently (and that works fine
so far) -- we should not include include/arch/x86/arch/lib.h
in include/lib.h, but rather change the Makefile to add the
include/arch/x86 path to the includes.

The only drawback is that we cannot have files with the same name
in include/arch/FOO/arch/ and include/ (but that's already the case
for the current files).
> Index: include/arch/x86/arch/lib.h
>
> --- include/arch/x86/arch/lib.h	(revision 0)
> +++ include/arch/x86/arch/lib.h	(revision 0)
> @@ -0,0 +1,26 @@
> +/*
> This file is part of the LinuxBIOS project.
> Copyright (C) 2007 Ron Minnich
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; version 2 of the License.
> This program is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU General Public License for more details.
> You should have received a copy of the GNU General Public License
> along with this program; if not, write to the Free Software
> Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> */
>
> +#ifndef ARCH_X86_LIB_H
> +#define ARCH_X86_LIB_H

Should be ARCH_X86_ARCH_LIB_H now (yes, looks stupid, but so does the
directory hierarchy :)
> +void uart_init(void);
> +void rtc_init(int invalid);
> +void isa_dma_init(void);
>
> +#endif /* ARCH_X86_LIB_H */

Ditto here.

Uwe.

[ron minnich]

On 6/25/07, Uwe Hermann  wrote:
> I think we handle this differently currently (and that works fine
> so far) -- we should not include include/arch/x86/arch/lib.h
> in include/lib.h, but rather change the Makefile to add the
> include/arch/x86 path to the includes.
>
> The only drawback is that we cannot have files with the same name
> in include/arch/FOO/arch/ and include/ (but that's already the case
> for the current files).

Right, I did this arch/lib.h thing in response to a request; people
did not like arch/x86/lib.h in includes. I personally like it, as it
reduces "magic".

I would rather NOT have the arch directory, and i would rather NOT
have duplicate names like lib.h.

So, quick, somebody, make a suggestion. Where do we put cpu-dependent
library functions? cpu.h?

ron

[Peter Stuge]

On Mon, Jun 25, 2007 at 04:16:04PM -0700, ron minnich wrote:
> Right, I did this arch/lib.h thing in response to a request; people
> did not like arch/x86/lib.h in includes. I personally like it, as
> it reduces "magic".

We shouldn't need "magic" - just some simple logic.

Ie. 1:1 rules for what files go together - clear relationships
between include/ and all that used to be in src/.
> I would rather NOT have the arch directory, and i would rather NOT
> have duplicate names like lib.h.

include/lib.h currently has:

log2, {u,m,}delay, beep_{short,long}, smbus_read_byte, ram_failure
and ram_initialize.

Shouldn't they just go into separate .h files? Or shouldn't all of
the other files go into lib.h? I'm sorry if I've forgotten what we
thought about all of this.
> So, quick, somebody, make a suggestion. Where do we put
> cpu-dependent library functions? cpu.h?

Sounds good. In fact, include/arch/x86/cpu.h already has some (all?)
of the code in the lx patch.

//Peter

[ron minnich]

On 6/25/07, Peter Stuge  wrote:
> include/lib.h currently has:
>
> log2, {u,m,}delay, beep_{short,long}, smbus_read_byte, ram_failure
> and ram_initialize.
>
> Shouldn't they just go into separate .h files?

That's what made V2 "too greppy" in the words of one. No, I don't like it.
> Sounds good. In fact, include/arch/x86/cpu.h already has some (all?)
> of the code in the lx patch.

cpu.h it is. I hate lots of include files. It's too hard to find things.

ron

[Peter Stuge]

Sorry for being so quiet lately. Too much backlog. :(

Sorry also for only complaining again. :(

On Tue, Jun 26, 2007 at 12:57:40AM +0200, Uwe Hermann wrote:
> I think we handle this differently currently (and that works fine
> so far) -- we should not include include/arch/x86/arch/lib.h
> in include/lib.h, but rather change the Makefile to add the
> include/arch/x86 path to the includes.
>
> The only drawback is that we cannot have files with the same name
> in include/arch/FOO/arch/ and include/ (but that's already the case
> for the current files).
> > +#define ARCH_X86_LIB_H
>
> Should be ARCH_X86_ARCH_LIB_H now (yes, looks stupid, but so does
> the directory hierarchy :)

I agree - I don't like arch twice.

What problem does the arch+arch directories solve?

Is there something in include/arch/x86/ that is _not_ arch-specific?
Is x86/arch/ actually needed to structure many x86 files, or is it
just abused to have neater #includes ?

If so, perhaps we can solve it in the Makefile instead. I'd prefer
-Iinclude/arch/x86 and just #include <lib.h> - even if it's just
in include/lib.h it all looks so much neater if we don't have the
extra directories.

May be a bikeshed.

//Peter

[Stefan Reinauer]

* Uwe Hermann  [070626 00:57]:
> > +#include <arch/lib.h>
> >  #endif /* LIB_H */
>
> I think we handle this differently currently (and that works fine
> so far) -- we should not include include/arch/x86/arch/lib.h
> in include/lib.h, but rather change the Makefile to add the
> include/arch/x86 path to the includes.

We are getting too many archsomething files into the tree so we go back
to the old behavior. There was some discussion on the list a while ago
on this topic.

[Stefan Reinauer]

* Uwe Hermann  [070625 23:45]:
> This header doesn't have the "part of LinuxBIOS" line and the copyright
> holder.

Just for common understanding.. What is it good for?

[Uwe Hermann]

On Wed, Jun 27, 2007 at 11:12:11PM +0200, Stefan Reinauer wrote:
> Uwe Hermann  [070625 23:45]:
> > This header doesn't have the "part of LinuxBIOS" line and the copyright
> > holder.
>
> Just for common understanding.. What is it good for?

I think I've explained this once or twice in the past, it's a good thing
to mark the origin of the code. Just like we incorporate code chunks from
other projects (Linux, Mozilla, LZMA, etc.) our code will probably be
used elsewhere, too. This makes it _much_ easier to know who originally
wrote the code, when, who owns the copyright, aaand from which project
the code came. I had a really hard time trying to research some of the
file's origins/authors in the v2 code, I want don't want to make this
hard for others with our code...

Uwe.