> Now suppose one wants a large dev_t. Some people do.
<thumps table> 2.6 will support a large dev_t.
We need to make this happen.
> Then several steps are needed. One of these steps
> is the addition of the mknod64 system call.
> That is a nice small isolated step - part of the necessary
> user space interface. It can be done independently of any
> other steps. It was submitted, but is not in the present
> kernel. Why not? I do not recall anybody pointing out problems.
This precisely illustrates my point.
mknod64() and several other dev_t patches (ext2 and ext3 support,
especially) have stalled in -mm for months. The reason why I have not
moved ahead with them is that I am waiting to see the rest of the work.
Because it could be that Al has different ideas, or that someone else gets
down and completes the work and wants to do it differently. I simply do
Or it could be that nobody ends up doing the dev_t work at all, in which
case we end up with a pointless syscall sitting there.
> I think some of these large dev_t steps were somewhat urgent, because
> they were prerequisites for glibc changes. But they didnt happen.
> Linus took a bit from me, and you submitted a few steps from me,
> and then nothing. OK.
The patches stopped!
Please, if you want to finish off the dev_t work, send the rest of the
patches. We'll shake them down, allow Al to be rude about them, break
people's builds with them, crash their kernels, etc. When it is all settled
down and everyone is sufficiently happy, shoot them across to Linus.
That's why I run -mm, so people can make these large and evolving changes,
have them reviewed and understood without breaking Linus's tree and thereby
> Dave compared the patch submission process to TCP/IP.
> I agree, and go into exponential backoff. Try again after two weeks,
> three months, a year and a half.
> But if you want we can restart that particular series of patches.
> Or discuss, if there are things to discuss.
Sounds great, let's do it. Send patches against the current -mm, copy
Greg, Christoph and Al on them and let's wrap this thing up.
The only problem of which I'm aware is that they seem to still break
devicemapper a bit, but the fixes for that seem to be just a few days away.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:17 EST