Re: Larger dev_t

    From [e-mail] Sun Mar 25 05:26:51 2001

    On Sat, 24 Mar 2001 [e-mail] wrote:
    >
    > We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
    > this is already true in glibc.

    The fact that glibc is a quivering mass of bloat, and total and utter crap
    makes you suggest that the Linux kernel should try to be as similar as
    possible?

    Not a very strong argument.

    There is no way in HELL I will ever accept a 64-bit dev_t.

    I don't care one _whit_ about the fact that Ulrich Drepper thinks that
    it's a good idea to make things too large.

Funny.

Now what I wrote is that *I* am strongly in favor of sizeof(dev_t) = 8.
You think that I want bloat - in reality sizeof(dev_t) = 8 makes life
simpler.

My system here has for example in super.c:

static dev_t next_unnamed_device = 0x10000000000ULL;

kdev_t get_unnamed_dev(void) {
        return to_kdev_t(next_unnamed_device++);
}

void put_unnamed_dev(kdev_t dev) {
}

a large name space allows one to omit checking what part can be
reused - reuse is unnecessary. That is also why I use a 64-bit pid:
upon a fork one does not have to search for pids, pgrps, sessions
with a given pid, and getpid() can be

static int get_pid(unsigned long flags) {
	if (flags & CLONE_PID)
		return current->pid;
	spin_lock(&lastpid_lock);
	++last_pid;
	spin_unlock(&lastpid_lock);
	return last_pid;
}

fast, simple, avoiding obscure security problems.
Yes, a large name space makes life simpler.

Now concerning this dev_t:
Outside the kernel we have glibc and it is 64 bits.
Inside the kernel we have a pointer to a device struct.
The kernel idea of the size of dev_t only plays a role
on the system call interface.

Really, I see no advantages at all restricting the interface
to something smaller than what user space and kernel use.
And saying "12 bits is enough for a major" somehow sounds funny.

Andries