Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932381AbWBMSDn (ORCPT ); Mon, 13 Feb 2006 13:03:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932382AbWBMSDn (ORCPT ); Mon, 13 Feb 2006 13:03:43 -0500 Received: from zproxy.gmail.com ([64.233.162.201]:31375 "EHLO zproxy.gmail.com") by vger.kernel.org with ESMTP id S932381AbWBMSDm convert rfc822-to-8bit (ORCPT ); Mon, 13 Feb 2006 13:03:42 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YQkqcmHIS0Lirc7pZHC0rowzUgyQ1ttr9aw5YuVX7qth3ce17T0MgcuPazNhkATJzNDZN9I/Oe4o3xbeb9GUvFERFobBDFUbkmR89aEMJ2oKj1WdLlXARefHK+QlMjg5rrZRTKrX9bE8zKkAjJX0VXuL6vdvQ0TCEXMow3c1r20= Message-ID: Date: Mon, 13 Feb 2006 13:03:38 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: Greg KH Subject: Re: CD writing in future Linux (stirring up a hornets' nest) Cc: Daniel Barkalow , Bill Davidsen , Nix , Jens Axboe , Joerg Schilling , linux-kernel@vger.kernel.org In-Reply-To: <20060213175142.GB20952@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <43D7AF56.nailDFJ882IWI@burner> <20060125173127.GR4212@suse.de> <43D7C1DF.1070606@gmx.de> <878xt3rfjc.fsf@amaterasu.srvr.nix> <43ED005F.5060804@tmr.com> <20060210235654.GA22512@kroah.com> <20060213062158.GA2335@kroah.com> <20060213175142.GB20952@kroah.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1646 Lines: 37 On 2/13/06, Greg KH wrote: > On Mon, Feb 13, 2006 at 03:05:49AM -0500, Daniel Barkalow wrote: > > On Sun, 12 Feb 2006, Greg KH wrote: > > > > > On Mon, Feb 13, 2006 at 12:01:48AM -0500, Daniel Barkalow wrote: > > > > sysfs doesn't do quite that level of categorization; if it did, cdrom_id > > > > would be unnecessary. > > > > > > What? cdrom_id queries the device directly to get some specific > > > information about the device, much like any other type of device query > > > (lspci, lsusb, etc.) > > > > > > And yes, it would be nice if some of that information was also exported > > > through sysfs, and as always, patches are gladly accpeted. > > > > Are there guidelines on having a generic cdrom export information from its > > block interface, rather than through its bus? I'm not finding any > > documentation of sys/block/, aside from that it exists. > > That information should go into the device directory, not the sys/block > directory (as it referrs to the device attributes, not the block gendev > attributes.) > Not necessarily - it would be easier for userspace programs if we had a separate class in sysfs - /sys/class/cdrom. The problem with this approach is that we do not allow a device belong o several classes without introducing intermediate class devices (I mean a DVD+RW shoudl probably belong to classes cdrom, dvdrom, cdwriter and dvdwriter). -- Dmitry - 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/