linux-kernel - Re: [microblaze-uclinux] [PATCH 03/11] microblaze: fall back on generic header files for the ABI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A4D9D41.5090006@monstr.eu>
Date:	Fri, 03 Jul 2009 07:55:13 +0200
From:	Michal Simek <monstr@...str.eu>
To:	microblaze-uclinux@...e.uq.edu.au
CC:	John Williams <john.williams@...alogix.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Remis Lima Baima <remis.developer@...glemail.com>,
	John Linn <John.Linn@...inx.com>,
	Michal Simek <monstr@...str.eu>
Subject: Re: [microblaze-uclinux] [PATCH 03/11] microblaze: fall back on generic
 header files for the ABI



Arnd Bergmann wrote:
> On Thursday 02 July 2009, John Williams wrote:
>> However, we've just "broken" the ABI in 2.6.31, if we merge further
>> ABI breakage in 2.6.32 it's more pain and confusion.
>>
>> So, unless we can merge and validate this ABI breakage during the
>> 2.6.31-rc cycle, I think we need to hold on changes that would break
>> the ABI again, so soon.
>>
>> Longer term there will be a complete redo of glibc up to the latest
>> version, which will obviously require a new toolchain for users - I
>> think that is the right place to do the next round of ABI breakage.
>>
>> Any thoughts?
> 
> Normally the rule is to never break the ABI at all, even in a major
> update of glibc.
> 
> Initially I had hoped that we could do the change before 2.6.30 and
> I worked hard on getting the ABI patches to you early enough for
> that. After that failed, I made sure that you had everything in
> place for 2.6.31 and I believed that Michal said he would integrate
> that in the microblaze-mmu merge, before you actually start seeing
> users on the mainline kernel.

we are talking about minor change - I know it break ABI a little bit
but don't be scared with it.
Two changes - first ssize_t is no problem - just warning messages
Second change kernel_mode_t from short to int breaks only ipc structures.
We are working on solving problem about another IPC trouble. I found a problem with
some syscalls which needs to be fixed in kernel and glibc - we will need newest toolchain
for it in any case. John just wanted to be sure that we will have working correct version.
I added most of your patches to my next branch for testing. I expect that Stephen merge it to next soon.

Thanks for your work,
Michal


> 
> If we don't get that into 2.6.31 any more (and the chances
> have slimmed down a lot after the end of the merge window), I
> think we should just declare complete failure and not touch
> the ABI any more, however broken it may be. 
> 
> In over 14 months, not even the most basic fixes to the ABI
> that I mentioned in the first review have been applied:
> 
> On Tuesday 15 April 2008, Michal Simek wrote:
>> Arnd Bergmann wrote:
>>> * Your syscall ABI is largely obsolete. A third of the syscalls you
>>> define should not even be there in the first place as they have been
>>> replaced by newer versions. E.g. you have select, _newselect and pselect6,
>>> where just pselect6 would be sufficient -- you don't need to worry about
>>> backwards compatibility if you don't have existing code. A good start
>>> would be to take the arch/blackfin syscall list and further reduce it
>>> from there. Further examples are:
>>> - replace socketcall with separate syscall entry points
>>> - replace ipc with a separate entry points
>>> - remove all the legacy signal handling from arch/microblaze/kernel/signal.c
>>> - remove sys_mmap, sys_olduname and sys_vfork
>>> - finally define a generic sys_mmap2 and sys_uname in kernel/ so you don't
>>>   need another copy in arch/microblaze/kernel
>>> - Use 64 bit off_t, and 32 bit uid_t, gid_t etc.
>> This kernel don't need to keep backward compatibility. No one will port to
>> previous version. I'll look at your points and I'll send you what I do.
> 
> 	Arnd <><
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@...e.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 
> 

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/