From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932069AbWFSFzj (ORCPT ); Mon, 19 Jun 2006 01:55:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932160AbWFSFzj (ORCPT ); Mon, 19 Jun 2006 01:55:39 -0400 Received: from wx-out-0102.google.com ([66.249.82.200]:18365 "EHLO wx-out-0102.google.com") by vger.kernel.org with ESMTP id S932069AbWFSFzi (ORCPT ); Mon, 19 Jun 2006 01:55:38 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BLxSGRQC6qBBq89519zQ6TwRI8N8hbaBSj1IcMM3/wIbm7R0JAbeixb5KinpJsB8GlS8nVPd2iEWNcm7A7yFL2RxSKibiG/fHtcYPT1VYSEpRXxF6Cn5X0Y8SwgtIvLqPS/P0VgrUeY5+F1MMUEFoGDYlxfii7Klf0+VwySLrJ4= Message-ID: <8e6f94720606182255u400964c2v1ea16221ffc5c94d@mail.gmail.com> Date: Mon, 19 Jun 2006 01:55:37 -0400 From: "Will Dyson" To: "H. Peter Anvin" Subject: Re: [GIT PATCH] Remove devfs from 2.6.17 Cc: "Joshua Hudson" , linux-kernel@vger.kernel.org In-Reply-To: <4495FF59.2010100@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060618221343.GA20277@kroah.com> <20060618230041.GG4744@bouh.residence.ens-lyon.fr> <4495F5C3.1030203@zytor.com> <4495FF59.2010100@zytor.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 6/18/06, H. Peter Anvin wrote: > Joshua Hudson wrote: > > With udev, you could mknod it yourself (in your application), then open it. > > That would fire up the auto-module-load. > > Sure, but it would be even better if pointing udev to a set of modules > (or perhaps a file generated by depmod) and have it do it all automatically. Providing the information about what devices a virtual driver will register when loaded seems like a good idea. Something like the following occurs to me. But it doesn't deal with loop's ability to register a different number of minors based on a module parameter. Not really sure what to do about that. Going in this direction is also a further impediment to dynamicly assigned device numbers. diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 9c3b94e..b933f3f 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1205,6 +1205,18 @@ static struct block_device_operations lo .ioctl = lo_ioctl, }; +static struct virtual_device_table loop_virt_tbl= { + {LOOP_MAJOR, 0, 1}, + {LOOP_MAJOR, 1, 1}, + {LOOP_MAJOR, 2, 1}, + {LOOP_MAJOR, 3, 1}, + {LOOP_MAJOR, 4, 1}, + {LOOP_MAJOR, 5, 1}, + {LOOP_MAJOR, 6, 1}, + {LOOP_MAJOR, 7, 1}, + {} +}; + /* * And now the modules code and kernel interface. */ @@ -1212,6 +1224,7 @@ module_param(max_loop, int, 0); MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)"); MODULE_LICENSE("GPL"); MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR); +MODULE_DEVICE_TABLE (virtual, loop_virt_tbl); int loop_register_transfer(struct loop_func_table *funcs) { diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h index f697770..f4a21d0 100644 --- a/include/linux/mod_devicetable.h +++ b/include/linux/mod_devicetable.h @@ -297,4 +297,16 @@ struct input_device_id { kernel_ulong_t driver_info; }; +/* + * Declare the intention of a driver to register a virtual + * device upon loading. + */ +struct virtual_device_id { + __u32 major; + __u32 minor; + __u8 type; /* 0 for char, 1 for block */ + + kernel_ulong_t driver_info; +} + #endif /* LINUX_MOD_DEVICETABLE_H */ -- Will Dyson