public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: neilb@cse.unsw.edu.au, torvalds@transmeta.com,
	trond.myklebust@fys.uio.no
Cc: linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: NFS "dev_t" issues..
Date: Wed, 2 Jan 2002 04:52:15 GMT	[thread overview]
Message-ID: <UTC200201020452.EAA175954.aeb@cwi.nl> (raw)

> I made a pre6, which contains a new-and-anal "kdev_t".

Nice! And even in my original form, with these heavy kdev_same
and kdev_none things :-).

I booted a kernel but had quite a lot to change, the patch
is large. I can send it, but instead:

(i) I changed almost every single MKDEV to mk_kdev.
Of course, the kernel was rather kdev_t clean, it was
not difficult to run with kdev_t a different type, so
there are very few places where this is inappropriate,
and the number of correct places is so large that a
global command, followed by a revert in these very few
places, seems more appropriate than a large patch.
Moreover, probably you and others did part of this already.

Not to be changed:
./init/do_mounts.c: sys_mknod("/dev/console", S_IFCHR|0600, MKDEV(TTYAUX_MAJOR, 1));
./arch/sparc64/solaris/fs.c: sys_mknod((const char *)A(path), mode, MKDEV(major,minor));
./include/linux/kdev_t.h

All else should be changed (or at least: did I change, I may have
overlooked sth).

In do_mounts.c there is a real_root_dev set via /proc, and I left it
an integer, while ROOT_DEV is a kdev_t, which implies the
appropriate conversions there.

(ii) Then there are MAJOR and MINOR. I did not change these to
major and minor, mainly because in some possible futures
it will be necessary to do a lot of grepping for these again -
almost all occurrences should be removed - and major and minor
are such common words. It is nicer to have something more unique,
like kmajor and kminor. Moreover, major and minor do at present
also occur as ordinary variables.
Are kmajor, kminor acceptable?

Andries


             reply	other threads:[~2002-01-02  4:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-02  4:52 Andries.Brouwer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-01-01 22:15 NFS "dev_t" issues Linus Torvalds
2002-01-01 22:15 Linus Torvalds
2002-01-01 22:57 ` Alexander Viro
2002-01-01 23:27   ` Linus Torvalds
2002-01-02  5:45 ` Greg KH
2002-01-07 16:50 ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=UTC200201020452.EAA175954.aeb@cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=neilb@cse.unsw.edu.au \
    --cc=torvalds@transmeta.com \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox