Messages in this thread | | | Date | Sun, 25 Mar 2001 14:31:13 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | Re: 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/
| |