Userspace visible of 3 include/asm/ headers

Userspace visible of 3 include/asm/ headers

[Adrian Bunk]

Could anyone help me regarding the desired userspace visibility of the 
following three headers under include/asm/?


Header        : cpufeature.h
Architectures : i386, x86_64
Is there any reason why this header is exported to userspace?

Header        : setup.h
Architectures : i386, ia64, x86_64
Contents:
- COMMAND_LINE_SIZE on ia64, x86_64
- much more on i386
Should COMMAND_LINE_SIZE be visible to userspace?
Anything else from the i386 setup.h?

Header        : timex.h
Architectures : all architectures
Offers CLOCK_TICK_RATE on all architectures, but on some architectures
(like i386) this depends on the kernel configuration.
-> not a userspace header?


TIA
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Re: Userspace visible of 3 include/asm/ headers

[Dave Jones]

On Thu, Aug 03, 2006 at 09:39:52PM +0200, Adrian Bunk wrote:
 > Could anyone help me regarding the desired userspace visibility of the 
 > following three headers under include/asm/?
 > 
 > 
 > Header        : cpufeature.h
 > Architectures : i386, x86_64
 > Is there any reason why this header is exported to userspace?

Probably not. The only apps I've seen that care about feature bits
define them theirselves rather than use these.

 > Header        : setup.h
 > Architectures : i386, ia64, x86_64
 > Contents:
 > - COMMAND_LINE_SIZE on ia64, x86_64
 > - much more on i386
 > Should COMMAND_LINE_SIZE be visible to userspace?

Bootloaders probably need to know this.

 > Header        : timex.h
 > Architectures : all architectures
 > Offers CLOCK_TICK_RATE on all architectures, but on some architectures
 > (like i386) this depends on the kernel configuration.
 > -> not a userspace header?

Also longer term,  CLOCK_TICK_RATE will make no sense should we go
to a tickless kernel.

		Dave

-- 
http://www.codemonkey.org.uk

Re: Userspace visible of 3 include/asm/ headers

[Alexey Dobriyan]

On Thu, Aug 03, 2006 at 03:44:10PM -0400, Dave Jones wrote:
> On Thu, Aug 03, 2006 at 09:39:52PM +0200, Adrian Bunk wrote:
>  > Could anyone help me regarding the desired userspace visibility of the
>  > following three headers under include/asm/?
>  >
>  > Header        : cpufeature.h
>  > Architectures : i386, x86_64
>  > Is there any reason why this header is exported to userspace?
>
> Probably not. The only apps I've seen that care about feature bits
> define them theirselves rather than use these.

Feature bits are only (indirectly) visible via /proc/cpuinfo.
struct cpuinfo_x86, AFAICS, is never copied to userspace. So, it's safe
to remove this header.

Re: Userspace visible of 3 include/asm/ headers

[Dave Jones]

On Fri, Aug 04, 2006 at 12:14:02AM +0400, Alexey Dobriyan wrote:
 > On Thu, Aug 03, 2006 at 03:44:10PM -0400, Dave Jones wrote:
 > > On Thu, Aug 03, 2006 at 09:39:52PM +0200, Adrian Bunk wrote:
 > >  > Could anyone help me regarding the desired userspace visibility of the
 > >  > following three headers under include/asm/?
 > >  >
 > >  > Header        : cpufeature.h
 > >  > Architectures : i386, x86_64
 > >  > Is there any reason why this header is exported to userspace?
 > >
 > > Probably not. The only apps I've seen that care about feature bits
 > > define them theirselves rather than use these.
 > 
 > Feature bits are only (indirectly) visible via /proc/cpuinfo.
 > struct cpuinfo_x86, AFAICS, is never copied to userspace. So, it's safe
 > to remove this header.

Most of the bits (all but the linux specific ones), are the same bits you
can get from /dev/cpu/0/cpuid, or from calling the cpuid instruction by hand.

		Dave

-- 
http://www.codemonkey.org.uk

Re: Userspace visible of 3 include/asm/ headers

[H. Peter Anvin]

Dave Jones wrote:
> 
>  > Header        : setup.h
>  > Architectures : i386, ia64, x86_64
>  > Contents:
>  > - COMMAND_LINE_SIZE on ia64, x86_64
>  > - much more on i386
>  > Should COMMAND_LINE_SIZE be visible to userspace?
> 
> Bootloaders probably need to know this.
> 

COMMAND_LINE_SIZE should be moved to a different header and be made 
common between all architectures.

	-hpa

Re: Userspace visible of 3 include/asm/ headers

[Adrian Bunk]

On Thu, Aug 03, 2006 at 02:28:43PM -0700, H. Peter Anvin wrote:
> Dave Jones wrote:
> >
> > > Header        : setup.h
> > > Architectures : i386, ia64, x86_64
> > > Contents:
> > > - COMMAND_LINE_SIZE on ia64, x86_64
> > > - much more on i386
> > > Should COMMAND_LINE_SIZE be visible to userspace?
> >
> >Bootloaders probably need to know this.
> >
> 
> COMMAND_LINE_SIZE should be moved to a different header and be made 
> common between all architectures.

On different architectures, we have the following values for 
COMMAND_LINE_SIZE:
- 256
- 512
- 896
- 1024
- 4096

What should be the common value?
4096?

And I have a rough memory of some dependencies of COMMAND_LINE_SIZE and 
boot loaders. What exactly must be taken care of when increasing 
COMMAND_LINE_SIZE?

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Userspace visible of 3 include/asm/ headers

[H. Peter Anvin]

Adrian Bunk wrote:

> 
> On different architectures, we have the following values for 
> COMMAND_LINE_SIZE:
> - 256
> - 512
> - 896
> - 1024
> - 4096
> 
> What should be the common value?
> 4096?
> 
> And I have a rough memory of some dependencies of COMMAND_LINE_SIZE and 
> boot loaders. What exactly must be taken care of when increasing 
> COMMAND_LINE_SIZE?
> 

It's architecture-dependent; it probably should be defined in something 
like <asm/cmdline.h>.

	-hpa

Re: Userspace visible of 3 include/asm/ headers

[Adrian Bunk]

On Thu, Aug 03, 2006 at 04:51:38PM -0700, H. Peter Anvin wrote:
> Adrian Bunk wrote:
> 
> >
> >On different architectures, we have the following values for 
> >COMMAND_LINE_SIZE:
> >- 256
> >- 512
> >- 896
> >- 1024
> >- 4096
> >
> >What should be the common value?
> >4096?
> >
> >And I have a rough memory of some dependencies of COMMAND_LINE_SIZE and 
> >boot loaders. What exactly must be taken care of when increasing 
> >COMMAND_LINE_SIZE?
> >
> 
> It's architecture-dependent; it probably should be defined in something 
> like <asm/cmdline.h>.

OK, I did misunderstand you.
I tought you were saying it should be the same value for all 
architectures.

With the exception of frv (in param.h), COMMAND_LINE_SIZE is in setup.h 
on all architectures.

Do we want to move it to a different header, or simply make param.h a 
userspace header on all architectures?

> 	-hpa

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Userspace visible of 3 include/asm/ headers

[H. Peter Anvin]

Adrian Bunk wrote:
> On Thu, Aug 03, 2006 at 04:51:38PM -0700, H. Peter Anvin wrote:
>> Adrian Bunk wrote:
>>
>>> On different architectures, we have the following values for 
>>> COMMAND_LINE_SIZE:
>>> - 256
>>> - 512
>>> - 896
>>> - 1024
>>> - 4096
>>>
>>> What should be the common value?
>>> 4096?
>>>
>>> And I have a rough memory of some dependencies of COMMAND_LINE_SIZE and 
>>> boot loaders. What exactly must be taken care of when increasing 
>>> COMMAND_LINE_SIZE?
>>>
>> It's architecture-dependent; it probably should be defined in something 
>> like <asm/cmdline.h>.
> 
> OK, I did misunderstand you.
> I tought you were saying it should be the same value for all 
> architectures.
> 
> With the exception of frv (in param.h), COMMAND_LINE_SIZE is in setup.h 
> on all architectures.
> 
> Do we want to move it to a different header, or simply make param.h a 
> userspace header on all architectures?
> 

I figure it should be broken out into a separate header, rather than 
exporting all of setup.h.

	-hpa

Re: Userspace visible of 3 include/asm/ headers

[H. Peter Anvin]

Nevermind, I just realized I did a brainfart.  setup.h should all be 
exported.

	-hpa