From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 May 2001 20:14:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 May 2001 20:14:46 -0400 Received: from mta1.snfc21.pbi.net ([206.13.28.122]:49606 "EHLO mta1.snfc21.pbi.net") by vger.kernel.org with ESMTP id ; Tue, 15 May 2001 20:14:32 -0400 Date: Tue, 15 May 2001 17:13:12 -0700 From: David Brownell Subject: Re: LANANA: To Pending Device Number Registrants To: Alexander Viro Cc: mjfrazer@somanetworks.com, lkml Message-id: <049e01c0dd9c$ff9eae80$6800000a@brownell.org> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-Priority: 3 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > I suppose that for network interface names, some convention for > > interface ioctls would suffice to solve that "identify" step. PCI > > devices would return the slot_name, USB devices need something > > like a patch I posted to linux-usb-devel a few months back. > > This is crap. Only the ioctl part, though I confess to trolling for a better proposal ... :) > If you want to do it - do it right. Accessing /dev/eth//MAC > is trivial. Wanking with ioctls is not. And populating such tree > is as simple as it gets. For links without a stable MAC, /.../net//{pci-slot,usb-path,...} is more like it, but I think that class of solution should be fine. Now ... what should be the roles of "regular" file ops, devfs, usbdevfs, procfs, and "devreg" ? That's the part that doesn't seem simple yet. I'd expect a few rounds of code/design changes. - Dave