Jürg Billeter wrote:
> I know that it's far from ideal but the only ideal way I see would be to
> extensively add __KERNEL__ ifdefs to the linux headers upstream so that
> the script could recognize automatically which headers are
> kernel-internal. Unfortunately this probably won't happen in the
On Sam, 2006-03-18 at 19:22 +, Ken Moffat wrote:
> On Sat, 18 Mar 2006, Jrg Billeter wrote:
>
> > Could you post the error message? What exact header set did you use?
> > Just removing linux/compiler.h without removal of compiler.h references
> > and the correct seds for __user etc. is likely
On Sat, 18 Mar 2006, J�rg Billeter wrote:
Could you post the error message? What exact header set did you use?
Just removing linux/compiler.h without removal of compiler.h references
and the correct seds for __user etc. is likely to fail.
Not for the first time, I've produced a duff bug report
Jürg Billeter wrote:
> On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
>> Jürg Billeter wrote:
>>
>>> - asterisk: Uses linux/compiler.h, include line could just be removed as
>>> linux/ixjuser.h doesn't need the compiler.h defines due to the seds we
>>> apply to the headers
>> Then
On Sam, 2006-03-18 at 16:10 +, Ken Moffat wrote:
> On Sat, 18 Mar 2006, Jrg Billeter wrote:
>
> > On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
> >> Then better make linux/compiler.h an empty file.
> >
> > If you want to go for best compatibility, sure; I currently aim to get
On Sat, 18 Mar 2006, J�rg Billeter wrote:
On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
Then better make linux/compiler.h an empty file.
If you want to go for best compatibility, sure; I currently aim to get
the header set as clean as possible, i.e. applications including
un
On Sam, 2006-03-18 at 08:56 +0500, Alexander E. Patrakov wrote:
> Jürg Billeter wrote:
>
> > - asterisk: Uses linux/compiler.h, include line could just be removed as
> > linux/ixjuser.h doesn't need the compiler.h defines due to the seds we
> > apply to the headers
>
> Then better make linux/comp
Jürg Billeter wrote:
- asterisk: Uses linux/compiler.h, include line could just be removed as
linux/ixjuser.h doesn't need the compiler.h defines due to the seds we
apply to the headers
Then better make linux/compiler.h an empty file.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/ma
On Sam, 2006-03-18 at 08:50 +1100, Greg Schafer wrote:
> Jürg Billeter wrote:
> > * headers-list: Sorted list of all found header references
> > * headers-xref: Header list cross-referenced to the package names
> > (useful to exclude header references of kernel module source code that's
> > unfor
Jürg Billeter wrote:
> I've also run a script to find used kernel headers over the sources of
> the 800 packages (except kernel and headers packages). You can find the
> results on http://www.paldo.org/headers/
Wow. Again, excellent work.
> * headers-list: Sorted list of all found header refere
On Die, 2006-03-14 at 22:01 +0100, Jürg Billeter wrote:
> On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
> > * Verify headers with real applications
> >Will do a full distro (800 packages) recompilation with these headers
> > sometime this week and fix headers resp. applications as ne
On Die, 2006-03-14 at 21:49 -0600, DJ Lucas wrote:
> Jürg. I haven't really looked into it, other than a grep through glibc
> source, but would it be acceptable to replace these headers with
> something like the following (example taken from llh linux/socket.h):
>
>
Jürg Billeter wrote:
Short preliminary report after rebuilding the base system (about 240
packages). Following problems found so far:
Looking very promising! :-)
- iproute2: Uses linux/if.h and linux/ip.h instead of net/if.h and
netinet/ip.h.
- nmap: Uses linux/if.h instead of net/if.h.
On Mit, 2006-03-15 at 09:11 +1100, Greg Schafer wrote:
> Jürg Billeter wrote:
>
> > Very short rationale is given on top of each file group. Detailed
> > rationale for each header would unfortunately be too time consuming.
>
> Hmmm, that's not ideal. I'm assuming you've looked at each header and
Jürg Billeter wrote:
> Very short rationale is given on top of each file group. Detailed
> rationale for each header would unfortunately be too time consuming.
Hmmm, that's not ideal. I'm assuming you've looked at each header and used
your judgement to determine whether it should be removed or no
On Die, 2006-03-14 at 13:27 -0800, Jim Gifford wrote:
> Jürg Billeter wrote:
> > On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
> >
> > Short preliminary report after rebuilding the base system (about 240
> > packages). Following problems found so far:
> >
> > - dvd+rw-tools: /\b__user/
Jürg Billeter wrote:
On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
Short preliminary report after rebuilding the base system (about 240
packages). Following problems found so far:
- dvd+rw-tools: /\b__user/ matched a struct in linux/capability.h whose
name starts with __user. Fixed
On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
> * Verify headers with real applications
>Will do a full distro (800 packages) recompilation with these headers
> sometime this week and fix headers resp. applications as necessary
Short preliminary report after rebuilding the base syst
On Mit, 2006-03-15 at 06:27 +1100, Greg Schafer wrote:
> Jürg Billeter wrote:
>
> > Yes, LLH fails that criteria and it ships with a lot of kernel-only
> > stuff. Based on Jim's script I've written an extended version which
> > removes a lot of headers that shouldn't be part of the linux glibc
> >
Thanks for your comments.
On Die, 2006-03-14 at 13:05 -0500, Bryan Kadzban wrote:
> On Tue, Mar 14, 2006 at 02:10:27PM +0100, J?rg Billeter wrote:
> > a="$(echo -ne '\001')"
> > b="$(echo -ne '\002')"
>
> These can probably be simplified to:
>
> a=$'\001'
> b=$'\002'
Didn't know that, changed.
Jürg Billeter wrote:
> Yes, LLH fails that criteria and it ships with a lot of kernel-only
> stuff. Based on Jim's script I've written an extended version which
> removes a lot of headers that shouldn't be part of the linux glibc
> header set, AFAICT.
Cool. But one has to ask how you arrived at t
On Tue, Mar 14, 2006 at 02:10:27PM +0100, J?rg Billeter wrote:
> a="$(echo -ne '\001')"
> b="$(echo -ne '\002')"
These can probably be simplified to:
a=$'\001'
b=$'\002'
> pushd $KERNEL_PATH/include
I don't think you need to pushd at the start and then popd at the end of
the script. The script
First, thanks to the work so far to all involved.
On Die, 2006-03-14 at 14:59 +1100, Greg Schafer wrote:
> Bryan Kadzban wrote:
> > I've been running Alexander's tests
> > (http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056159.html)
>
> I agree with Alexander that every userspace heade
Bryan Kadzban wrote:
> gccver=`gcc -dumpversion`
Oops, that doesn't need to be there anymore...
(I attempted at one point to add -nostdinc to the gcc command line, so I
needed to add the system header location
(/usr/lib/gcc/$MACHTYPE/$gccver/include) to the search path. That
seemed to fail, and
Greg Schafer wrote:
> Bryan Kadzban wrote:
>
>> I've been running Alexander's tests
>> (http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056159.html)
>>
>
> I agree with Alexander that every userspace header should be
> compilable by itself (at least in an ideal world). Note that curren
Bryan Kadzban wrote:
> Greg Schafer wrote:
>> echo '/* empty */' > linux/compiler.h
>
> Hmm... Is this really necessary?
It is if you want to duplicate LLH. I should have added in my post that
the above change requires more sanitization eg: removing __user, __force,
__nocast, __deprecated, etc.
Greg Schafer wrote:
> echo '/* empty */' > linux/compiler.h
Hmm... Is this really necessary? I've been running Alexander's tests
(http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056159.html)
on the output of Jim's script, and right now, it looks like
include/linux/byteorder/swab.h is cho
Jim Gifford wrote:
> Just added a compare script. That will compare the difference between the
> raw_headers produced with the headers script compared to the headers in
> llh.
Jim, I've been working along similar lines. I'm getting the diff down all
the time. I've included some stuff below which
Just added a compare script. That will compare the difference between
the raw_headers produced with the headers script compared to the headers
in llh.
The bad news is only will work with the 2.6.12 headers, since there
isn't a new release.
Usage is ./compare 2.6.12 2.6.12.0
29 matches
Mail list logo
