glibc-kernel-headers: ainstr_fm.h (HEAD) ainstr_iw.h (HEAD) ainstr_simple.h (HEAD)

[Jakub Bogusz]

On Sat, Dec 20, 2003 at 07:28:00PM +0100, Mariusz Mazur wrote:
> On Saturday 20 of December 2003 17:42, Jakub Bogusz wrote:
> > Oj, za bardzo się pospieszyłem :(
> > To używa makra __cpu_to_be32(), zdefiniowanego tylko w tych
> > nieszczęsnych <linux/*_endian.h>
> >
> > Te same makra (bez "__") są używane w <linux/*_fs.h>...
> >
> > Chyba trzeba jednak udostępnić <asm/byteorder.h> dla części nagłówków
> > (tylko tych wymagających) :/
> > Ale te makra chyba trzeba przerobić, żeby korzystały z glibcowych bswap_
> > - one na x86 używają bswap w zależności od opcji kompilatora, a nie
> > CONFIG_* z konfiguracji jądra.
> > Chyba że ktoś ma inny pomysł?
> 
> Skoro gibc udostępnia też odpowiednie makra do konwersji,

I glibc i jądro udostępniają makra do zamiany kolejności bajtów słowie
(bswap_{16,32,64} w glibc, __swab{16,32,64} w nagłówkach jądra)...

> to w takim razie po 
> co ma być dostępny asm/byteorder.h?

...ale to (a dokładniej <linux/byteorder/*>) udostępnia dodatkowo makra
cpu_to_{b,l}e{16,32,64}, które okazują się być używane w nagłówkach co
najmniej alsy i systemów plików.

> (te nagłówki są oby napewno potrzebne dla userlandu? bo mam zamiar powywalać z 
> katalogu sound nadmiarowe)

ainstr_*.h są używane w alsa-lib (z tym, że własne kopie; do tego tam
w samym kodzie są używane makra __cpu_to_*).

<linux/ext2_fs.h>[1] jest używane przez parę programów (ext2ed[2], mc;
e2fsprogs ma swoją wersję, z własnymi makrami skopiowanymi z tamtych)
Pliki do innych systemów plików zapewne przez narzędzia do tych systemów
plików (z wyjątkiem tych mających własne wersje - np. reiserfsprogs ma,
ale z brzydkim hackiem).

[1] swoją drogą ten plik jest aktualnie zepsuty - włącza
<linux/ext2_fs_sb.h>, które włącza dwa pliki włączające już jakieś
bebechy (config.h, spinlock.h itd.).
ext3 tak samo.

[2] wg komentarza w e2fsprogs, gdzie też są te źródła włączone, ten
program działa tylko na 32-bitowych LE - proponuję dodać ExclusiveArch,
żeby ktoś sobie krzywdy nie zrobił - i tak nie będzie działać
A że nie obsługuje systemów plików >2GB to już inna sprawa.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/