public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* NFS "dev_t" issues..
@ 2002-01-01 22:15 Linus Torvalds
  2002-01-01 22:38 ` [PATCH] " Jeff Garzik
                   ` (7 more replies)
  0 siblings, 8 replies; 16+ messages in thread
From: Linus Torvalds @ 2002-01-01 22:15 UTC (permalink / raw)
  To: Trond Myklebust, Neil Brown; +Cc: Kernel Mailing List, Marcelo Tosatti


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

The format of the thing is the same as it used to be, ie 16 bits of
information, but I made it a structure so that you _couldn't_ mix up
"dev_t" and "kdev_t", or use the "kdev_t" as a number (so when kdev_t
expands to 12+20 bits later in 2.5.x you shouldn't get surprises)

I fixed up the stuff I use and which showed up in compiles (on a source
level, it's so far totally untested), but I'd really like people to check
out their own subsystems. _Especially_ NFS and NFSD, which had several
cases of mixing the two dev_t's around, and which also used them as
numbers. Trond, Neil?

Because the types aren't at all compatible any more, the macros that are
used for user-level "dev_t" are no longer working for a kdev_t. So we have

	dev_t			kdev_t

	MKDEV(major,minor)	mk_kdev(major, minor)
	MAJOR(dev)		major(dev)
	MINOR(dev)		minor(dev)
	dev == dev2		kdev_same(dev, dev2)
	!dev			kdev_none(dev)

and _most_ of the time the fixes are trivial - just translate as above. It
only gets interesting when you have code that looks at the value or starts
mixing the two and compares a "dev_t" against a "kdev_t", which can be
quite interesting.

The knfsd file handle thing is also an issue - Neil, please check out that
what I did looks sane, and would be on-the-wire-compatible with the old
behaviour, even when we expand kdev_t to 12+20 bits, ok?

(Marcelo, for easier backporting of drivers to 2.4.x, we'll probably want
to eventually add

	#define mk_kdev(a,b) MKDEV(a,b)
	#define major(d) MAJOR(d)
	...

to the 2.4.x <linux/kdev_t.h> so that you can move drivers back and
forth).

Apart from some knfsd issues, most of the kdev_t users were proper. The
strict type-checking found one bug in the SCSI layer (which I knew about,
and was one of the impetuses for doing it in the first place), and found a
lot of small "works-but-will-break-with-a-bigger-kdev_t" issues).

			Linus


^ permalink raw reply	[flat|nested] 16+ messages in thread
* NFS "dev_t" issues..
@ 2002-01-01 22:15 Linus Torvalds
  0 siblings, 0 replies; 16+ messages in thread
From: Linus Torvalds @ 2002-01-01 22:15 UTC (permalink / raw)
  To: zaitcev, Trond Myklebust, Neil Brown; +Cc: Kernel Mailing List, Marcelo Tosatti


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

The format of the thing is the same as it used to be, ie 16 bits of
information, but I made it a structure so that you _couldn't_ mix up
"dev_t" and "kdev_t", or use the "kdev_t" as a number (so when kdev_t
expands to 12+20 bits later in 2.5.x you shouldn't get surprises)

I fixed up the stuff I use and which showed up in compiles (on a source
level, it's so far totally untested), but I'd really like people to check
out their own subsystems. _Especially_ NFS and NFSD, which had several
cases of mixing the two dev_t's around, and which also used them as
numbers. Trond, Neil?

Because the types aren't at all compatible any more, the macros that are
used for user-level "dev_t" are no longer working for a kdev_t. So we have

	dev_t			kdev_t

	MKDEV(major,minor)	mk_kdev(major, minor)
	MAJOR(dev)		major(dev)
	MINOR(dev)		minor(dev)
	dev == dev2		kdev_same(dev, dev2)
	!dev			kdev_none(dev)

and _most_ of the time the fixes are trivial - just translate as above. It
only gets interesting when you have code that looks at the value or starts
mixing the two and compares a "dev_t" against a "kdev_t", which can be
quite interesting.

The knfsd file handle thing is also an issue - Neil, please check out that
what I did looks sane, and would be on-the-wire-compatible with the old
behaviour, even when we expand kdev_t to 12+20 bits, ok?

(Marcelo, for easier backporting of drivers to 2.4.x, we'll probably want
to eventually add

	#define mk_kdev(a,b) MKDEV(a,b)
	#define major(d) MAJOR(d)
	...

to the 2.4.x <linux/kdev_t.h> so that you can move drivers back and
forth).

Apart from some knfsd issues, most of the kdev_t users were proper. The
strict type-checking found one bug in the SCSI layer (which I knew about,
and was one of the impetuses for doing it in the first place), and found a
lot of small "works-but-will-break-with-a-bigger-kdev_t" issues).

			Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: NFS "dev_t" issues..
@ 2002-01-02  4:52 Andries.Brouwer
  0 siblings, 0 replies; 16+ messages in thread
From: Andries.Brouwer @ 2002-01-02  4:52 UTC (permalink / raw)
  To: neilb, torvalds, trond.myklebust; +Cc: linux-kernel, marcelo

> 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


^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-01-09  4:05 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-01-01 22:15 NFS "dev_t" issues Linus Torvalds
2002-01-01 22:38 ` [PATCH] " Jeff Garzik
2002-01-01 22:41   ` Linus Torvalds
2002-01-01 22:57 ` Alexander Viro
2002-01-01 23:27   ` Linus Torvalds
2002-01-01 23:04 ` [PATCH] " Jeff Garzik
2002-01-01 23:26   ` Linus Torvalds
2002-01-01 23:49     ` Jeff Garzik
2002-01-02  5:45 ` Greg KH
2002-01-02 16:05 ` [PATCH] Make 2.5.2-pre6 usable Martin Dalecki
2002-01-03 15:11 ` [PATCH] usabe2-2.5.2-pre6 Martin Dalecki
2002-01-07 16:50 ` NFS "dev_t" issues Trond Myklebust
2002-01-08  9:29 ` PATCH 2.5.2-pre9 scsi cleanup Martin Dalecki
2002-01-09  4:05   ` GOTO Masanori
  -- strict thread matches above, loose matches on Subject: below --
2002-01-01 22:15 NFS "dev_t" issues Linus Torvalds
2002-01-02  4:52 Andries.Brouwer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox