lkml.org 
[lkml]   [2001]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Larger dev_t
    From torvalds@transmeta.com Sun Mar 25 05:26:51 2001

On Sat, 24 Mar 2001 Andries.Brouwer@cwi.nl 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
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:17    [W:2.391 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site