Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 27 Mar 2001 18:59:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 27 Mar 2001 18:59:48 -0500 Received: from neon-gw.transmeta.com ([209.10.217.66]:7436 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Tue, 27 Mar 2001 18:59:35 -0500 Date: Tue, 27 Mar 2001 15:57:51 -0800 (PST) From: Linus Torvalds To: Andre Hedrick cc: Alan Cox , "H. Peter Anvin" , , , Subject: Re: Larger dev_t In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Mar 2001, Andre Hedrick wrote: > > Am I hearing you state you want dynamic device points and dynamic majors? Yes and no. We need static structures for user space - from a user perspective it makes a ton more sense to say "I want to see all disks" than it does to know that you have to do /dev/hd*, /dev/sd* plus all the extra magic combinations that can happen (USB etc). So in a sense what I'm arguing for is for _stricter_ device numbers to the outside world. But internally, it would be reasonably easy to make a mapping from those user-visible numbers to a much looser version. One example of this is going to happen very early in 2.5.x: the whole "partitioning" stuff is going to go away from the driver, and into the ll_rw_block layer as just another disk re-mapping thing. We already do those kinds of re-mappings for LVM reasons anyway, and partitioning is not something a disk driver should know about, really. And that kind of partitioning mapping automatically means that we'd need to remap minor numbers, and do it on a per-major basis (because the partitioning mapping right now is not actually the same between SCSI and IDE: IDE uses six bits of partitioning, while SCSI uses just four bits). And once you do that, you might as well start "remapping" major numbers too. So let's say that you have two separate SCSI controllers - they would both show up on major #8, and different minor numbers. Right now, for example, controller 1 might have one disk, with minors 0-15 (for the whole disk and 15 partitions), and controller 2 might have two disks using minors 16-47. As it stands now, the SCSI layer needs to do the remapping, and because the SCSI layer does the remapping, nothing but SCSI layer devices can use major #8. But once you start doing partition mapping in ll_rw_block.c, you might as well get rid of the notion that "SCSI is major 8". You could easily have many different drivers, with many different queues, and remap them all to have major 8 (and different minors) so that it looks simple for a user that just wants to see SCSI disks. Which is not to say that the same disk might not show up somewhere else too, if anybody wants it to. The _driver_ should just know "unit x on queue y", and then the driver might do whatever it wants (it might be, for example, that the driver actually wants to show multiple controllers as one queue, if the driver really wants to for some reason). And it should be possible to have two drivers that really have no idea at ALL about each other to just share the same major numbers. 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/