klibc and SPARC

klibc and SPARC

[H. Peter Anvin]

Hello all,

As most of you know, I'm trying to move a bunch of Linux
initialization code into early userspace, "klibc".  This is now in
2.6.17-rc4-mm1, and I've gotten a sparc64-related bug report,
specifially related to the following:

[arch/sparc64/kernel/setup.c]


#ifdef CONFIG_IP_PNP
        if (!ic_set_manually) {
                int chosen = prom_finddevice ("/chosen");
                u32 cl, sv, gw;

                cl = prom_getintdefault (chosen, "client-ip", 0);
                sv = prom_getintdefault (chosen, "server-ip", 0);
                gw = prom_getintdefault (chosen, "gateway-ip", 0);
                if (cl && sv) {
                        ic_myaddr = cl;
                        ic_servaddr = sv;
                        if (gw)
                                ic_gateway = gw;
#if defined(CONFIG_IP_PNP_BOOTP) || defined(CONFIG_IP_PNP_RARP)
                        ic_proto_enabled = 0;
#endif
                }
        }
#endif

Is there a way to get that information from userspace, and if not,
should there be a general way to do it or an ad hoc solution?  It sort
of looks like arch/sparc64/prom describes a form of filesystem, but I
don't see any obvious userspace interface.

	-hpa

Re: klibc and SPARC

[David S. Miller]

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 17 May 2006 13:37:12 -0700 (PDT)

> Is there a way to get that information from userspace, and if not,
> should there be a general way to do it or an ad hoc solution?  It sort
> of looks like arch/sparc64/prom describes a form of filesystem, but I
> don't see any obvious userspace interface.

There are two ways.

First option is to mount the "openpromfs" filesystem under
/proc/openprom, the full firmware device tree and properties are
available under there as a filesystem.

The second option is to load the /dev/openprom driver, which you open,
and then access using ioctls() defined in <asm/openpromio.h>

Re: klibc and SPARC

[H. Peter Anvin]

Followup to:  <20060517.134042.27108210.davem@davemloft.net>
By author:    "David S. Miller" <davem@davemloft.net>
In newsgroup: linux.dev.sparclinux
>
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: Wed, 17 May 2006 13:37:12 -0700 (PDT)
> 
> > Is there a way to get that information from userspace, and if not,
> > should there be a general way to do it or an ad hoc solution?  It sort
> > of looks like arch/sparc64/prom describes a form of filesystem, but I
> > don't see any obvious userspace interface.
> 
> There are two ways.
> 
> First option is to mount the "openpromfs" filesystem under
> /proc/openprom, the full firmware device tree and properties are
> available under there as a filesystem.

Just found that ;)

> The second option is to load the /dev/openprom driver, which you open,
> and then access using ioctls() defined in <asm/openpromio.h>

Does it make sense to say that these prom configurations are only
recognized by kinit if openpromfs is available (without which it will
simply behave as on any other platform), or should I go through the
additional trouble of supporting both methods?

	-hpa

Re: klibc and SPARC

[H. Peter Anvin]

[Resend to fix Cc: list]

Followup to:  <20060517.134042.27108210.davem@davemloft.net>
By author:    "David S. Miller" <davem@davemloft.net>
In newsgroup: linux.dev.sparclinux
 >
 > From: "H. Peter Anvin" <hpa@zytor.com>
 > Date: Wed, 17 May 2006 13:37:12 -0700 (PDT)
 >
 > > Is there a way to get that information from userspace, and if not,
 > > should there be a general way to do it or an ad hoc solution?  It sort
 > > of looks like arch/sparc64/prom describes a form of filesystem, but I
 > > don't see any obvious userspace interface.
 >
 > There are two ways.
 >
 > First option is to mount the "openpromfs" filesystem under
 > /proc/openprom, the full firmware device tree and properties are
 > available under there as a filesystem.

Just found that ;)

 > The second option is to load the /dev/openprom driver, which you open,
 > and then access using ioctls() defined in <asm/openpromio.h>

Does it make sense to say that these prom configurations are only
recognized by kinit if openpromfs is available (without which it will
simply behave as on any other platform), or should I go through the
additional trouble of supporting both methods?

         -hpa

Re: klibc and SPARC

[David S. Miller]

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 17 May 2006 13:43:58 -0700 (PDT)

> Does it make sense to say that these prom configurations are only
> recognized by kinit if openpromfs is available (without which it will
> simply behave as on any other platform), or should I go through the
> additional trouble of supporting both methods?

You need to enable a particular driver either way,
either CONFIG_SUN_OPENPROMFS or CONFIG_SUN_OPENPROMIO.

The NFS configuration bits you are moving into klibc
are going to be expected to work even if both of those
config options are disabled, it's expected to always
be available and work.

Re: klibc and SPARC

[H. Peter Anvin]

David S. Miller wrote:
>> Does it make sense to say that these prom configurations are only
>> recognized by kinit if openpromfs is available (without which it will
>> simply behave as on any other platform), or should I go through the
>> additional trouble of supporting both methods?
> 
> You need to enable a particular driver either way,
> either CONFIG_SUN_OPENPROMFS or CONFIG_SUN_OPENPROMIO.
> 
> The NFS configuration bits you are moving into klibc
> are going to be expected to work even if both of those
> config options are disabled, it's expected to always
> be available and work.

Sounds like you're saying I should force one of those drivers enabled, is that right?  I'm 
fine with that.  The other alternative is of course to put an ad hoc thing for this thing; 
that seems unnecessarily ugly to me but if necessary I can do that as well.

If I should force one of the drivers enabled, which one should it be (I'm assuming 
CONFIG_SUN_OPENPROMFS?)

	-hpa

Re: klibc and SPARC

[David S. Miller]

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 17 May 2006 15:36:21 -0700

> David S. Miller wrote:
> >> Does it make sense to say that these prom configurations are only
> >> recognized by kinit if openpromfs is available (without which it will
> >> simply behave as on any other platform), or should I go through the
> >> additional trouble of supporting both methods?
> > 
> > You need to enable a particular driver either way,
> > either CONFIG_SUN_OPENPROMFS or CONFIG_SUN_OPENPROMIO.
> > 
> > The NFS configuration bits you are moving into klibc
> > are going to be expected to work even if both of those
> > config options are disabled, it's expected to always
> > be available and work.
>
> Sounds like you're saying I should force one of those drivers
> enabled, is that right?  I'm fine with that.  The other alternative
> is of course to put an ad hoc thing for this thing; that seems
> unnecessarily ugly to me but if necessary I can do that as well.
>
> If I should force one of the drivers enabled, which one should it be
> (I'm assuming CONFIG_SUN_OPENPROMFS?)

How I answer this depends upon why you're moving this out of the
kernel in the first place :-)

I can understand moving as much functionality as is reasonably
possible into userspace via klibc, but for something like this which
has weird dependencies if you move it into userspace and will
undoubtedly force the enabling of what is normally an optional
feature, I don't see moving it into userspace as being so wise.

That being said, openpromfs is the preferred thing to use if
you have to make a choice.

Re: klibc and SPARC

[H. Peter Anvin]

David S. Miller wrote:
> How I answer this depends upon why you're moving this out of the
> kernel in the first place :-)

The goal is mainly to get rid of a bunch of complex code that doesn't have to be in the 
kernel, like nfsroot.

> I can understand moving as much functionality as is reasonably
> possible into userspace via klibc, but for something like this which
> has weird dependencies if you move it into userspace and will
> undoubtedly force the enabling of what is normally an optional
> feature, I don't see moving it into userspace as being so wise.

OK, so that would make it an ad hoc thing.  That's not too horrible in itself; I just 
wondered if it would make sense to use an already existing feature.

However, there are a number of theoretically optional features in the kernel kernel which 
kinit does depend on, in particular sysfs and procfs -- without which it would be largely 
impossible.  It doesn't mean sysfs and procfs are mandatory, but it does mean that you 
have to provide your own initramfs if you don't want to include them.

Of course, unlike say openpromfs, very little userspace code will actually function 
without procfs, and increasingly sysfs, so it's not exactly a requirement imposed by kinit 
alone.

> That being said, openpromfs is the preferred thing to use if
> you have to make a choice.

Well, I'm happy to do it either which way.  I'll go ahead and write up an ad hoc solution 
for this case, unless it turns out to actually be bigger than one of the generic codes.

	-hpa

Re: klibc and SPARC

[David S. Miller]

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Wed, 17 May 2006 16:10:51 -0700

> Well, I'm happy to do it either which way.  I'll go ahead and write
> up an ad hoc solution for this case, unless it turns out to actually
> be bigger than one of the generic codes.

Note you could export these specific values via procfs/sysfs.

Just an idea...

Re: klibc and SPARC

[H. Peter Anvin]

David S. Miller wrote:
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: Wed, 17 May 2006 16:10:51 -0700
> 
>> Well, I'm happy to do it either which way.  I'll go ahead and write
>> up an ad hoc solution for this case, unless it turns out to actually
>> be bigger than one of the generic codes.
> 
> Note you could export these specific values via procfs/sysfs.
> 
> Just an idea...

Right, that's pretty much what I was planning to do.

	-hpa

Re: klibc and SPARC

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

David S. Miller wrote:
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: Wed, 17 May 2006 16:10:51 -0700
> 
>> Well, I'm happy to do it either which way.  I'll go ahead and write
>> up an ad hoc solution for this case, unless it turns out to actually
>> be bigger than one of the generic codes.
> 
> Note you could export these specific values via procfs/sysfs.
> 
> Just an idea...

After thinking about it some more, I decided to drop the information into a file in the 
rootfs.  That way there is no "normal runtime" memory footprint, which would be the main 
reason to avoid the normal drivers.

The kernel side of the patch is attached for review; there is obviously also a kinit side 
which I haven't written yet (I'll try to finish the whole thing this evening.)

	-hpa


[-- Attachment #2: sparc64.arch.diff --]
[-- Type: text/x-patch, Size: 3033 bytes --]

diff --git a/arch/sparc64/kernel/setup.c b/arch/sparc64/kernel/setup.c
index 005167f..a124cb0 100644
--- a/arch/sparc64/kernel/setup.c
+++ b/arch/sparc64/kernel/setup.c
@@ -102,7 +102,7 @@ int obp_system_intr(void)
 	return 0;
 }
 
-/* 
+/*
  * Process kernel command line switches that are specific to the
  * SPARC or that require special low-level processing.
  */
@@ -315,6 +315,53 @@ static void __init sun4v_patch(void)
 	}
 }
 
+/*
+ * Platform-specific configuration commands which don't come from
+ * the actual kernel command line.  Write them into a file in rootfs
+ * so kinit can pick them up.
+ */
+static void __init set_arch_init_commands(void)
+{
+	int fd = sys_open("/arch.cmd", O_WRONLY|O_CREATE|O_APPEND, 0666);
+	int chosen = prom_finddevice ("/chosen");
+	u32 cl, sv, gw;
+	char buffer[256];
+	int len = 0;
+
+	if (fd < 0)
+		return;
+
+	cl = prom_getintdefault (chosen, "client-ip", 0);
+	sv = prom_getintdefault (chosen, "server-ip", 0);
+	gw = prom_getintdefault (chosen, "gateway-ip", 0);
+
+#ifdef CONFIG_BLK_DEV_RAM
+	len = min(sizeof buffer - 1,
+		  snprintf(buffer, sizeof buffer,
+			   "ramdisk_start=%u\n"
+			   "prompt_ramdisk=%d\n"
+			   "load_ramdisk=%d\n",
+			   ram_flags & RAMDISK_IMAGE_START_MASK,
+			   !!(ram_flags & RAMDISK_PROMPT_FLAG),
+			   !!(ram_flags & RAMDISK_LOAD_FLAG)));
+#endif
+	if (cl && sv) {
+		len += min(sizeof buffer - 1 - len,
+			   snprintf(buffer+len, sizeof buffer - len,
+				    "ip=%u.%u.%u.%u:%u.%u.%u.%u:"
+				    "%u.%u.%u.%u\n",
+				    (u8)(cl >> 24), (u8)(cl >> 16),
+				    (u8)(cl >> 8), (u8)cl,
+				    (u8)(sv >> 24), (u8)(sv >> 16),
+				    (u8)(sv >> 8), (u8)sv,
+				    (u8)(gw >> 24), (u8)(gw >> 16),
+				    (u8)(gw >> 8), (u8)gw));
+	}
+
+	sys_write(fd, buffer, len);
+	sys_close(fd);
+}
+
 void __init setup_arch(char **cmdline_p)
 {
 	/* Initialize PROM console and command line. */
@@ -349,33 +396,10 @@ #endif
 	if (!root_flags)
 		root_mountflags &= ~MS_RDONLY;
 	ROOT_DEV = old_decode_dev(root_dev);
-#ifdef CONFIG_BLK_DEV_RAM
-	rd_image_start = ram_flags & RAMDISK_IMAGE_START_MASK;
-	rd_prompt = ((ram_flags & RAMDISK_PROMPT_FLAG) != 0);
-	rd_doload = ((ram_flags & RAMDISK_LOAD_FLAG) != 0);	
-#endif
 
 	task_thread_info(&init_task)->kregs = &fake_swapper_regs;
 
-#ifdef CONFIG_IP_PNP
-	if (!ic_set_manually) {
-		int chosen = prom_finddevice ("/chosen");
-		u32 cl, sv, gw;
-		
-		cl = prom_getintdefault (chosen, "client-ip", 0);
-		sv = prom_getintdefault (chosen, "server-ip", 0);
-		gw = prom_getintdefault (chosen, "gateway-ip", 0);
-		if (cl && sv) {
-			ic_myaddr = cl;
-			ic_servaddr = sv;
-			if (gw)
-				ic_gateway = gw;
-#if defined(CONFIG_IP_PNP_BOOTP) || defined(CONFIG_IP_PNP_RARP)
-			ic_proto_enabled = 0;
-#endif
-		}
-	}
-#endif
+	set_arch_init_commands();
 
 	smp_setup_cpu_possible_map();
 
@@ -439,7 +463,7 @@ static int ncpus_probed;
 
 static int show_cpuinfo(struct seq_file *m, void *__unused)
 {
-	seq_printf(m, 
+	seq_printf(m,
 		   "cpu\t\t: %s\n"
 		   "fpu\t\t: %s\n"
 		   "prom\t\t: %s\n"

Re: klibc and SPARC

[David S. Miller]

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Thu, 18 May 2006 12:17:20 -0700

> The kernel side of the patch is attached for review; there is
> obviously also a kinit side which I haven't written yet (I'll try to
> finish the whole thing this evening.)

This looks fine to me.

I assume you'll submit this once the kinit bits are done?

Re: klibc and SPARC

[H. Peter Anvin]

David S. Miller wrote:
> From: "H. Peter Anvin" <hpa@zytor.com>
> Date: Thu, 18 May 2006 12:17:20 -0700
> 
>> The kernel side of the patch is attached for review; there is
>> obviously also a kinit side which I haven't written yet (I'll try to
>> finish the whole thing this evening.)
> 
> This looks fine to me.
> 
> I assume you'll submit this once the kinit bits are done?

Yes, I'll merge it into my klibc tree once I have it working (I did get my old Ultra2 to 
come back to life yesterday...) and ask akpm to pull it.

	-hpa