grackle, patches, MMU, ...

grackle, patches, MMU, ...

[Benjamin Herrenschmidt]

Hi All !

I finally read the pmac_pci.c file and it looks like my grackle.h file
(which comes from experiments I made on MacOS some time ago for another
issue) is absolutely not needed, grackle is just device 0 on bus 0 and
it's register can be accessed by ordinary pci config accesses. However,
since I know no easy way of knowing which bridge in the list is actually
grackle, if we want to add power management support for it in idle.c,
we'll still have to hard code device 0 / bus 0 and hope it will always be
this way.

I'll post a cleaned up set of patches with only the safe ones to simplify
merging (I'm waiting some stuff from Tom Rini to complete the ADB+mice
patches) but do you (you=people doing the merge with Linus tree) prefer
patches against current vger (still at 2.1.130) or directly against Linus
2.2-pre1 ?

I also spent some time looking at the MMU initialisations, and it looks
like we are using one BAT on powermacs for mac-io and that's all. PREP is
using two, APUS too. BATs 2 and 3 are used to map physical RAM for the
kernel, that's it ?

So we have one free BAT (#1) only on pmac and chrp, but if we plan to
switch BATs along with process contexts (for mapping fbdevs with BATs for
example), then we would have all BATs free for user processes. Am I correct ?

I was wondering if, instead of using the remaining free BAT to map the
framebuffer for the kernel (to speed up console), why couldn't we use a
BAT to map the entire assigned PCI memory space for the kernel ? This
would speed-up accesses to all devices (including framebuffers). We
already map the entire mac-io (at least the first one on machines with
two of them).

Finally, a last question: on machines with two mac-io's, like the recent
PowerBooks, the /proc/device-tree is broken when booting with bootx: the
names inside pathnames don't have the '@xxxxxx' that OF appends and so
both mac-io have the same pathname. That makes almost impossible to reach
the second one from /proc.

I plan to fix that by adding @xxxxxx from bootx when building the
device-tree, but I'm annoyed because the find_path_device routine is not
smart enough to skip them when there is no confusion. For example,
find_path_device("/pci/mydevice") will fail if the full path of mydevice
is actullally "/pci@xxxxxxx/mydevice@yyyyyyy". Should I also fix that or
should we expect callers of find_path_device() to provide an exact path
all the time ? My idea was to make find_path_device ignore the @xxxxxx
except if they are specifically specified in the searched path.

Also, I don't know which value I'll put in xxxxxx, maybe just a ordering
number (begins with 0, incremented with each entry). The goal is just to
make sure that path are unique.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: grackle, patches, MMU, ...

[Geert Uytterhoeven]

On Wed, 30 Dec 1998, Benjamin Herrenschmidt wrote:
> I finally read the pmac_pci.c file and it looks like my grackle.h file
> (which comes from experiments I made on MacOS some time ago for another
> issue) is absolutely not needed, grackle is just device 0 on bus 0 and
> it's register can be accessed by ordinary pci config accesses. However,
> since I know no easy way of knowing which bridge in the list is actually
> grackle, if we want to add power management support for it in idle.c,
> we'll still have to hard code device 0 / bus 0 and hope it will always be
> this way.

Grackle is the host bridge, right? In that case it's always device 0 / bus 0.

> So we have one free BAT (#1) only on pmac and chrp, but if we plan to
> switch BATs along with process contexts (for mapping fbdevs with BATs for
> example), then we would have all BATs free for user processes. Am I correct ?

Note that we cannot map all frame buffers with BATs since there are less free
BATs than possible frame buffers.

> I was wondering if, instead of using the remaining free BAT to map the
> framebuffer for the kernel (to speed up console), why couldn't we use a
> BAT to map the entire assigned PCI memory space for the kernel ? This
> would speed-up accesses to all devices (including framebuffers). We
> already map the entire mac-io (at least the first one on machines with
> two of them).

I think they do this on SPARC64. And then ioremap() because a simple NULL
operation.

But for user space, we're still stuck with a normal mapping. And there speed is
more important, I think, since most people (R5 installers? :-) run X and don't
use the text console that much.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: grackle, patches, MMU, ...

[Benjamin Herrenschmidt]

On Wed, Dec 30, 1998, Geert Uytterhoeven
<Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:

>Grackle is the host bridge, right? In that case it's always device 0 / bus 0.

Yep.

>But for user space, we're still stuck with a normal mapping. And there speed
>is
>more important, I think, since most people (R5 installers? :-) run X and
don't
>use the text console that much.

Yes, having a way to use BATs for large user-space mappings would be a
benefit for framebuffer and also for other devices like frame grabbers.
I'm not familiar enough yet with the user-side MM stuff to implement this
now, but if no one does it, I'll try it as soon as I have undersood
enough things there.

BTW. Geert: Since you are working on m68k too, do you know if linux-m68k
uses the same adb code as linux-ppc ? I'm working on a new adb.c/.h,
which cleans up things (especially "hook-like" entry points to the
controller by exporting functions for registering hardware controllers
(via a structure with function pointers)) and for registering devices
(also a structure with function pointers with more entrypoint to allow
proper re-probing when a bus reset is done for example) and I would like
to know if there are risk I break m68k while doing so. Currently,
adb.c/.h is in arch/ppc but I don't know if vger is the main repository
for m68k too or not


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: grackle, patches, MMU, ...

[Geert Uytterhoeven]

On Wed, 30 Dec 1998, Benjamin Herrenschmidt wrote:
> BTW. Geert: Since you are working on m68k too, do you know if linux-m68k
> uses the same adb code as linux-ppc ? I'm working on a new adb.c/.h,

Linux/m68k on Mac uses arch/m68k/mac/adb-bus.c, drivers/char/adbmouse.c and
include/asm-m68k/adb.h. All these files are up-to-date in 2.2.0-pre1, AFAIK
(just diffed between pre1 and m68k-.131).

> which cleans up things (especially "hook-like" entry points to the
> controller by exporting functions for registering hardware controllers
> (via a structure with function pointers)) and for registering devices
> (also a structure with function pointers with more entrypoint to allow
> proper re-probing when a bus reset is done for example) and I would like
> to know if there are risk I break m68k while doing so. Currently,

Integration would be nice. Contact Michael Schmitz <mschmitz@lbl.gov> in case
of troubles.

> adb.c/.h is in arch/ppc but I don't know if vger is the main repository
> for m68k too or not

Vger isn't the main repository for m68k. The main things that keep Linus' tree
from working on m68k are IDE and serial. We're working on integrating IDE
(patches are ready), but I'm afraid Linus won't accept them. BTW, in 3 more
months I'll celebrate `5 year IDE in Linux/m68k' on my Amiga, with the driver
still not integrated... sigh...

The mandatory site for Linux/m68k kernels is
ftp://sunsite.auc.dk/pub/os/linux/680x0/.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: grackle, patches, MMU, ...

[Cort Dougan]

Against vger please.  I'll smooth out the vger/linus differences myself.

Getting things to Linus now is difficult with the 'real' freeze now.
Things are going to have to sit still for a while unless they really need
fixing.

}I'll post a cleaned up set of patches with only the safe ones to simplify
}merging (I'm waiting some stuff from Tom Rini to complete the ADB+mice
}patches) but do you (you=people doing the merge with Linus tree) prefer
}patches against current vger (still at 2.1.130) or directly against Linus
}2.2-pre1 ?

Right.  We only use 2 bats for the kernel if one won't cover it.

}I also spent some time looking at the MMU initialisations, and it looks
}like we are using one BAT on powermacs for mac-io and that's all. PREP is
}using two, APUS too. BATs 2 and 3 are used to map physical RAM for the
}kernel, that's it ?

The # of free bats depends on the machine.  We'd only have all the bats
free if we map without the BATS entirely.  We don't to switch between
mapping with and without BATS on the kernel depending on the process.

}So we have one free BAT (#1) only on pmac and chrp, but if we plan to
}switch BATs along with process contexts (for mapping fbdevs with BATs for
}example), then we would have all BATs free for user processes. Am I correct ?

PCI is a lot bigger than one bat.  On prep we map all the pci space we use
with a bat.

}I was wondering if, instead of using the remaining free BAT to map the
}framebuffer for the kernel (to speed up console), why couldn't we use a
}BAT to map the entire assigned PCI memory space for the kernel ? This
}would speed-up accesses to all devices (including framebuffers). We
}already map the entire mac-io (at least the first one on machines with
}two of them).


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: grackle, patches, MMU, ...

[Benjamin Herrenschmidt]

On Thu, Dec 31, 1998, Cort Dougan <cort@persephone.cs.nmt.edu> wrote:


>The # of free bats depends on the machine.  We'd only have all the bats
>free if we map without the BATS entirely.  We don't to switch between
>mapping with and without BATS on the kernel depending on the process.

Ok. I knew for the variable number of BATs. So currently, the BATs are
set once
for all for the kernel, and stay this way in user mode. Getting them
beeing switched on a per-process basis would require changes still beyond
my current knowledge about the kernel. I'll try to understand all this
and I'll eventually code some test stuffs. Once BATs are switched, we can
use them for large ioremaps.

>PCI is a lot bigger than one bat.  On prep we map all the pci space we use
>with a bat.

Yep, of course, I was thinking about what is currently allocated, and
this is usually fine for one BAT.

For the curious, MacOS uses BATs too, but it can only use BATs for PCI,
no pages :-( This makes things quite funny when trying to use several
cacheable regions on a board.


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: grackle, patches, MMU, ...

[Cort Dougan]

It'd be nice to have the BATs be a flexible commodity but how to do that
isn't clear.  If we can have a clean mechanism for doing it (much like
superpages) we can generalize it to the 8xx chips as well.

}Ok. I knew for the variable number of BATs. So currently, the BATs are
}set once


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

__init, __openfirmware, etc...

[Benjamin Herrenschmidt]

Hi all !

Could someone explain me how those directive (__init, __openfirmware,
__pmac, ...) works in the kernel ? I guess those are directive for the
linker, and I also guess that __init marked sections will be removed from
memory after kernel initialisation, but what are the other ones ? 

I ask this because I added a couple of ioctl to via-pmu (*), and as soon
as I added calls to get_user and put_user to the function, the kernel
refused to link. if I remove the __openfirmware directive from the ioctl
function, then it links fine.

(*) Cort, I have backlight control working on wallstreet, those ioctls
are for allowing user-space control of it too, I think you can remove
your stuff from via-pmu.c. I'll send you patches as soon as I have
cleaned them up a little bit, it's not urgent for 2.2.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: __init, __openfirmware, etc...

[Geert Uytterhoeven]

On Sat, 2 Jan 1999, Benjamin Herrenschmidt wrote:
> Could someone explain me how those directive (__init, __openfirmware,
> __pmac, ...) works in the kernel ? I guess those are directive for the
> linker, and I also guess that __init marked sections will be removed from
> memory after kernel initialisation, but what are the other ones ? 

__init sections are indeed removed after kernel initialisation. The other ones
are removed depending on the dynamic run type of the machine, e.g. __pmac
sections are removed on PReP, and so on. Saves quite some valuable unswappable
kernel memory.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: __init, __openfirmware, etc...

[Benjamin Herrenschmidt]

On Sat, Jan 2, 1999, Geert Uytterhoeven <geert@geert.cs.kuleuven.ac.be> wrote:

>__init sections are indeed removed after kernel initialisation. The
other ones
>are removed depending on the dynamic run type of the machine, e.g. __pmac
>sections are removed on PReP, and so on. Saves quite some valuable
unswappable
>kernel memory.c

Ok. Do you know what happens to static datas declared within an __init
function ? Is it removed to ? I have a function that use a static array
for putting permanent "override" values for part of the device tree and
this array must not be removed. Should I put the static array out of the
function too or will this remove mecanism avoid bss sections ?

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: __init, __openfirmware, etc...

[Geert Uytterhoeven]

On Sun, 3 Jan 1999, Benjamin Herrenschmidt wrote:
> On Sat, Jan 2, 1999, Geert Uytterhoeven <geert@geert.cs.kuleuven.ac.be> wrote:
> >__init sections are indeed removed after kernel initialisation. The
> other ones
> >are removed depending on the dynamic run type of the machine, e.g. __pmac
> >sections are removed on PReP, and so on. Saves quite some valuable
> unswappable
> >kernel memory.c
> 
> Ok. Do you know what happens to static datas declared within an __init
> function ? Is it removed to ? I have a function that use a static array
> for putting permanent "override" values for part of the device tree and
> this array must not be removed. Should I put the static array out of the

I think it will be removed. I suggest to use `nm' or `objdump' or just plain
`make dirhiearchy/file.S' to find out in which section the data end up.

Note that __init isn't perfect: especially tables with strings are difficult to
put in __init, e.g.

    const char *table __init = {
	"string 1", "string 2",
    }

will put the table with pointers in an init section, while the string data
itself is put in the normal data section, which is usually not what you want.
You can circumvent that in a tedious way like:

    static const char string1[] = "string 1";
    static const char string2[] = "string 2";
    const char *table __init = {
	string1, string2
    };

> function too or will this remove mecanism avoid bss sections ?

BSS sections are always empty (zeroed), so you can't store initial data in them
:-)

To put a BSS variable in an init section, make sure to put at least one
synthetic initializer in it, like

    const char bssvar[100] __init = { 0, };

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

real-root-dev patch for vger

[Brad Midgley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 777 bytes --]

a type problem has rendered /proc/sys/kernel/real-root-dev useless in the
vger tree. this problem has been around for quite a while. also attached. 

--- init/main.c.orig	Fri Jan  1 13:35:28 1999
+++ init/main.c	Mon Nov 30 16:01:56 1998
@@ -349,7 +349,7 @@
 extern int rd_size;		/* Size of the ramdisk(s) */
 extern int rd_image_start;	/* starting block # of image */
 #ifdef CONFIG_BLK_DEV_INITRD
-kdev_t real_root_dev;
+int real_root_dev;
 #endif
 #endif
 
--- include/linux/fs.h.orig	Fri Jan  1 13:35:12 1999
+++ include/linux/fs.h	Mon Nov 30 20:03:00 1998
@@ -850,7 +850,7 @@
 extern void mount_root(void);
 
 #ifdef CONFIG_BLK_DEV_INITRD
-extern kdev_t real_root_dev;
+extern int real_root_dev;
 extern int change_root(kdev_t new_root_dev,const char *put_old);
 #endif
 


[-- Attachment #2: Type: TEXT/PLAIN, Size: 648 bytes --]

--- init/main.c.orig	Fri Jan  1 13:35:28 1999
+++ init/main.c	Mon Nov 30 16:01:56 1998
@@ -349,7 +349,7 @@
 extern int rd_size;		/* Size of the ramdisk(s) */
 extern int rd_image_start;	/* starting block # of image */
 #ifdef CONFIG_BLK_DEV_INITRD
-kdev_t real_root_dev;
+int real_root_dev;
 #endif
 #endif
 
--- include/linux/fs.h.orig	Fri Jan  1 13:35:12 1999
+++ include/linux/fs.h	Mon Nov 30 20:03:00 1998
@@ -850,7 +850,7 @@
 extern void mount_root(void);
 
 #ifdef CONFIG_BLK_DEV_INITRD
-extern kdev_t real_root_dev;
+extern int real_root_dev;
 extern int change_root(kdev_t new_root_dev,const char *put_old);
 #endif
 

Re: real-root-dev patch for vger

[Geert Uytterhoeven]

On Fri, 1 Jan 1999, Brad Midgley wrote:
> a type problem has rendered /proc/sys/kernel/real-root-dev useless in the
> vger tree. this problem has been around for quite a while. also attached. 
> 
> --- init/main.c.orig	Fri Jan  1 13:35:28 1999
> +++ init/main.c	Mon Nov 30 16:01:56 1998
> @@ -349,7 +349,7 @@
>  extern int rd_size;		/* Size of the ramdisk(s) */
>  extern int rd_image_start;	/* starting block # of image */
>  #ifdef CONFIG_BLK_DEV_INITRD
> -kdev_t real_root_dev;
> +int real_root_dev;
>  #endif
>  #endif
>  
> --- include/linux/fs.h.orig	Fri Jan  1 13:35:12 1999
> +++ include/linux/fs.h	Mon Nov 30 20:03:00 1998
> @@ -850,7 +850,7 @@
>  extern void mount_root(void);
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> -extern kdev_t real_root_dev;
> +extern int real_root_dev;
>  extern int change_root(kdev_t new_root_dev,const char *put_old);
>  #endif
>  
> 
> 

This is a known problem on big endian machines. Was fixed in the m68k tree a
few years ago :-) I don't know why Linus doesn't take the patch Andreas Schwab
sent him, also many years ago.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: real-root-dev patch for vger

[Brad Midgley]

geert,

is the patch i submitted the same as the one you refer to? is the patch
safe for other architectures? i'll push for it if so.

brad

> 
> On Fri, 1 Jan 1999, Brad Midgley wrote:
> > a type problem has rendered /proc/sys/kernel/real-root-dev useless in the
> > vger tree. this problem has been around for quite a while. also attached. 
> > 
> > --- init/main.c.orig	Fri Jan  1 13:35:28 1999
> > +++ init/main.c	Mon Nov 30 16:01:56 1998
> > @@ -349,7 +349,7 @@
> >  extern int rd_size;		/* Size of the ramdisk(s) */
> >  extern int rd_image_start;	/* starting block # of image */
> >  #ifdef CONFIG_BLK_DEV_INITRD
> > -kdev_t real_root_dev;
> > +int real_root_dev;
> >  #endif
> >  #endif
> >  
> > --- include/linux/fs.h.orig	Fri Jan  1 13:35:12 1999
> > +++ include/linux/fs.h	Mon Nov 30 20:03:00 1998
> > @@ -850,7 +850,7 @@
> >  extern void mount_root(void);
> >  
> >  #ifdef CONFIG_BLK_DEV_INITRD
> > -extern kdev_t real_root_dev;
> > +extern int real_root_dev;
> >  extern int change_root(kdev_t new_root_dev,const char *put_old);
> >  #endif
> >  
> > 
> > 
> 
> This is a known problem on big endian machines. Was fixed in the m68k tree a
> few years ago :-) I don't know why Linus doesn't take the patch Andreas Schwab
> sent him, also many years ago.
> 
> Greetings,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
> Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
> Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
> 
> 


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: real-root-dev patch for vger

[Geert Uytterhoeven]

On Sun, 3 Jan 1999, Brad Midgley wrote:
> is the patch i submitted the same as the one you refer to? is the patch
> safe for other architectures? i'll push for it if so.

AFAIK it's safe. To be sure: Andreas?

> brad
> 
> > 
> > On Fri, 1 Jan 1999, Brad Midgley wrote:
> > > a type problem has rendered /proc/sys/kernel/real-root-dev useless in the
> > > vger tree. this problem has been around for quite a while. also attached. 
> > > 
> > > --- init/main.c.orig	Fri Jan  1 13:35:28 1999
> > > +++ init/main.c	Mon Nov 30 16:01:56 1998
> > > @@ -349,7 +349,7 @@
> > >  extern int rd_size;		/* Size of the ramdisk(s) */
> > >  extern int rd_image_start;	/* starting block # of image */
> > >  #ifdef CONFIG_BLK_DEV_INITRD
> > > -kdev_t real_root_dev;
> > > +int real_root_dev;

In the m68k tree, we have

    int real_root_dev;              /* MUST be int for sysctl! */

> > >  #endif
> > >  #endif
> > >  
> > > --- include/linux/fs.h.orig	Fri Jan  1 13:35:12 1999
> > > +++ include/linux/fs.h	Mon Nov 30 20:03:00 1998
> > > @@ -850,7 +850,7 @@
> > >  extern void mount_root(void);
> > >  
> > >  #ifdef CONFIG_BLK_DEV_INITRD
> > > -extern kdev_t real_root_dev;
> > > +extern int real_root_dev;
> > >  extern int change_root(kdev_t new_root_dev,const char *put_old);
> > >  #endif
> > >  
> > > 
> > > 
> > 
> > This is a known problem on big endian machines. Was fixed in the m68k tree a
> > few years ago :-) I don't know why Linus doesn't take the patch Andreas Schwab
> > sent him, also many years ago.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: real-root-dev patch for vger

[Andreas Schwab]

Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be> writes:

|> On Sun, 3 Jan 1999, Brad Midgley wrote:
|> > is the patch i submitted the same as the one you refer to? is the patch
|> > safe for other architectures? i'll push for it if so.
|> 
|> AFAIK it's safe. To be sure: Andreas?

Well, it should be safe as long as kdev_t isn't changed to be some complex
type, but in this case the sysctl interface has to be changed anyway.

|> > brad
|> > 
|> > > 
|> > > On Fri, 1 Jan 1999, Brad Midgley wrote:
|> > > > a type problem has rendered /proc/sys/kernel/real-root-dev useless in the
|> > > > vger tree. this problem has been around for quite a while. also attached. 
|> > > > 
|> > > > --- init/main.c.orig	Fri Jan  1 13:35:28 1999
|> > > > +++ init/main.c	Mon Nov 30 16:01:56 1998
|> > > > @@ -349,7 +349,7 @@
|> > > >  extern int rd_size;		/* Size of the ramdisk(s) */
|> > > >  extern int rd_image_start;	/* starting block # of image */
|> > > >  #ifdef CONFIG_BLK_DEV_INITRD
|> > > > -kdev_t real_root_dev;
|> > > > +int real_root_dev;
|> 
|> In the m68k tree, we have
|> 
|>     int real_root_dev;              /* MUST be int for sysctl! */

Looks pretty identical to me, as far as the compiler is concerned. :-)

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]