linux-kernel - Re: [PATCH 29/30] microblaze_mmu

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 27 Apr 2009 15:03:57 +0200
From:	Michal Simek <monstr@...str.eu>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, john.williams@...alogix.com
Subject: Re: [PATCH 29/30] microblaze_mmu_v1: stat.h MMU update

Arnd Bergmann wrote:
> On Monday 27 April 2009, Michal Simek wrote:
>> Long answer: in stat64 structure I wanted to find out more information
>> about stat64 structure. I mean there are some variables and they have different
>> types and I would like to know about more info.
>> For example
>> If make sense long long type for st_blocks. IMHO unsigned will be better.
>> And I would like to create new stat64 structure where is not a fault for both noMMU/MMU version.
>> In noMMU implementation is st_blocks unsigned long. Is it OK? or unsigned long long is better?
>>
> 
> I still think that there are major changes that should be done to the
> Microblaze ABI. I actually did most of the work for this, but then you
> beat be by getting it upstream first ;-)

For me is/was good that I could focus on MMU part and no to spend all my time to moving noMMU
patches and wait for future changes. Community is sending patches for Microblaze and for me is
easier to manage small changes not drag bunch of 50 patches to next version.

> 
> I suppose it's much too late for 2.6.30 now, but maybe we can do one major
> ABI change to microblaze by making the ABI totally generic in the next
> merge window. I'll follow up with an RFC for this.

If you propose me changes, I'll try to test it. If the results are OK, I'll add it to next merge
open window for Microblaze. As I wrote before I am open to your visions and if microblaze is in
mainline I can test it easier than before.

Thanks,
Michal



> 
> 	Arnd <><


-- 
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/