linux-kernel - Re: [PATCH] Unicore architecture patch review, part 2

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: <201012101410.37537.arnd@arndb.de>
Date:	Fri, 10 Dec 2010 14:10:37 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Guan Xuetao" <guanxuetao@...c.pku.edu.cn>
Cc:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Unicore architecture patch review, part 2

On Thursday 09 December 2010, Guan Xuetao wrote:
> > Did I misunderstand you or did you make up your mind since then?
> > 
> We do define new 32-bit ABI work at present, and I will use generic unistd
> in new ABI.
> But existing machines must be maintained, so many codes need remain
> compatibility.

Ok, I see.

I would suggest a slightly different approach here as a compromise:

Make a patch that contains the difference between the backwards-compatible
and the new ABI. With this, you can run the backwards-compatible
ABI internally, but send our the new ABI for inclusion in the mainline
kernel. Send out the patch between the two along with the other
patches and make it clear that you still depend on this patch but that
it is not meant to be included.

Nothing stops you from using the old ABI as long as you want to, since
you can always put the patch on top of any upstream kernel when you
make a system image. It is quite normal to have a few patches required
to get a working kernel, although of course everyone tries to keep these
to a minimum.

It is probably also a good time for you to start learning about managing
patches for a submission. Everyone does this a bit differently, but
there two basic tools that most people use:

* Quilt is a simple tool that manages plain files with patches that
  apply on top of each other. You can easily modify patches in the middle,
  keep a patch description for each one and reorder the patches. It
  is mostly compatible with git-send-email for submitting the patches
  to the mailing list. Typically, you will want to use the quilt series
  in combination with a sourcecode management tool like git, in order to
  keep a history of what you have done.

* Git can do everything that quilt does, besides doing many other things
  as well. The most important sub-command to learn here is 'git rebase -i',
  which lets you reorder changeset and insert or delete changesets in the
  middle of a branch. It takes somewhat longer to be productive with git
  rebase than with quilt, but I personally find it much more reliable.

stgit is a tool that tries to combine the features of quilt and git, but
as far as I can tell, most users have moved on to just using git by itself.

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