2006-08-03 19:39:57

by Adrian Bunk

[permalink] [raw]
Subject: Userspace visible of 3 include/asm/ headers

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


2006-08-03 19:45:21

by Dave Jones

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

2006-08-03 20:14:08

by Alexey Dobriyan

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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.

2006-08-03 20:18:26

by Dave Jones

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

2006-08-03 21:31:35

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

2006-08-03 21:52:35

by Adrian Bunk

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

2006-08-03 23:54:37

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

2006-08-04 00:12:25

by Adrian Bunk

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

2006-08-04 01:02:48

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

2006-08-04 01:03:52

by H. Peter Anvin

[permalink] [raw]
Subject: Re: Userspace visible of 3 include/asm/ headers

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

-hpa