On Mon, Dec 10, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > I also never advocated removing topology information. We already have it
> > via an ioctl call. I just don't want topology exposed in the directory
> > structure for usbdevfs.
> >
> > In that case, we're forcing the information o
> I also never advocated removing topology information. We already have it
> via an ioctl call. I just don't want topology exposed in the directory
> structure for usbdevfs.
>
> In that case, we're forcing the information on everyone if they care or
> not, and most programs don't care.
Hmm ... t
> but anyway, why limit usbdevfs to only devices which don't have kernel
> drivers? the end user should be able to decide what should drive a
> certain device, right?
That's a familiar issue. Even if there's a kernel driver for one
interface, a user mode one might be appropriate for a different
On Mon, Dec 10, 2001 at 02:21:18PM -0500, Dan Streetman wrote:
>
> but anyway, why limit usbdevfs to only devices which don't have kernel
> drivers? the end user should be able to decide what should drive a
> certain device, right?
I agree. I just didn't know of any devices that did this. Tha
On Mon, 10 Dec 2001, Greg KH wrote:
>On Mon, Dec 10, 2001 at 12:00:31PM -0500, Dan Streetman wrote:
>>
>> On Fri, 7 Dec 2001, Greg KH wrote:
>>
>> >I don't know of anyone using the usbdevfs interface on devices that have
>> >a kernel driver associated with it. Does anyone else?
>>
>> Yes, me. I
lt;[EMAIL PROTECTED]>
To: "Greg KH" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, December 10, 2001 9:00 AM
Subject: Re: [linux-usb-devel] Re: Q: device(file) permissions for USB
>
> On Fri, 7 Dec 2001, Greg KH wrote:
>
>
On Mon, Dec 10, 2001, Dan Streetman <[EMAIL PROTECTED]> wrote:
>
> On Sat, 8 Dec 2001, Johannes Erdfelt wrote:
>
> >The rest of the USB code just doesn't care. I think exposing it via
> >usbdevfs will just complicate things where it isn't needed.
>
> If multiple identical devices are connected,
On Mon, Dec 10, 2001 at 12:00:31PM -0500, Dan Streetman wrote:
>
> On Fri, 7 Dec 2001, Greg KH wrote:
>
> >I don't know of anyone using the usbdevfs interface on devices that have
> >a kernel driver associated with it. Does anyone else?
>
> Yes, me. I have to talk via usbdevfs to HID devices.
On Sat, 8 Dec 2001, Johannes Erdfelt wrote:
>The rest of the USB code just doesn't care. I think exposing it via
>usbdevfs will just complicate things where it isn't needed.
If multiple identical devices are connected, topology is the one and
only way for the user to differentiate between the d
On Fri, 7 Dec 2001, Greg KH wrote:
>I don't know of anyone using the usbdevfs interface on devices that have
>a kernel driver associated with it. Does anyone else?
Yes, me. I have to talk via usbdevfs to HID devices.
Of course I have to either not build the HID module at all (and then
my HID
On Sat, Dec 08, 2001 at 09:10:47PM -0800, David Brownell wrote:
> >
> > What cases? I don't know of cases that aren't just as hard as parsing
> > the device tree by walking the directories.
>
> Cases like: you're already walking the directories, so
> there's no reason to write a parser for "de
> The exception is "devfs", which hasn't been widely popular;
> in part that's because of the names it chose.
devfs is a seperate issue because you can also run everything off hotplug.
Its fine whether devfs creates nodes or the hotplug scripts get told
"a konica camera serial 1141551 mass stora
Am Sonntag, 9. Dezember 2001 05:46 schrieb David Brownell:
> > > Today that's a two level action. Devices' "true names" are
> > > triples {char or block, major, minor}, which make a finite
> > > set of names (16 bits today, 32 bits soonish) exposed
> > > as "dev_t" to userland ... for some device
> > > I don't know of anyone using the usbdevfs interface on devices that have
> > > a kernel driver associated with it. Does anyone else?
> >
> > Well, it's the clean way to construct the device tree in userland.
> > Parsing the "devices" file is problematic in various cases.
>
> What cases?
> > > In fact I also want to see the USB device tree exposed using better
> > > names -- as in, ones that expose the device tree, hubs in their proper
> > > places, instead of being based on unstable device addressing.
> >
> > So a topology tree? That's a good thing, and is what I think the
> >
> > Today that's a two level action. Devices' "true names" are
> > triples {char or block, major, minor}, which make a finite
> > set of names (16 bits today, 32 bits soonish) exposed
> > as "dev_t" to userland ... for some devices, but not all
> > (consider network interfaces). In some cases "d
On Sat, Dec 08, 2001 at 10:48:22PM -0500, Johannes Erdfelt wrote:
> On Sat, Dec 08, 2001, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > No, the topology can also be used for device naming. The Edgeport
> > driver (before it got merged into the kernel tree) used the topology to
> > specify the minor
On Sat, Dec 08, 2001, Greg KH <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 08, 2001 at 09:56:21PM -0500, Johannes Erdfelt wrote:
> > On Sat, Dec 08, 2001, Greg KH <[EMAIL PROTECTED]> wrote:
> > > So a topology tree? That's a good thing, and is what I think the
> > > driverfs interface will show (as t
On Sat, Dec 08, 2001 at 09:56:21PM -0500, Johannes Erdfelt wrote:
> On Sat, Dec 08, 2001, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > Ah, the whole device naming problem, which I see this thread has spun
> > off into. I'm staying away from that topic for now :)
>
> You can't say that. You took t
On Sat, Dec 08, 2001, Greg KH <[EMAIL PROTECTED]> wrote:
> > In general, when the questions involve mapping hardware (as
> > exposed by "usbfs" :) to logical devices (as exposed by kernel
> > drivers, and in some cases by smart enough apps), or vice
> > versa, neither "usbfs" nor the kernel driver
Oliver Neukum wrote:
>>Consider a system with multiple removable ATA HDDs. If the bays connect
>>to the host system via USB<->ATA bridges, the serial number that the
>>host sees will be that of the bay, not the HDD itself.
>>
>Which is as it should be.
>
Correct. My point is that the decision on
On Sat, Dec 08, 2001 at 06:29:11AM -0800, David Brownell wrote:
> > I don't know of anyone using the usbdevfs interface on devices that have
> > a kernel driver associated with it. Does anyone else?
>
> Well, it's the clean way to construct the device tree in userland.
> Parsing the "devices" fi
On Sat, Dec 08, 2001 at 04:08:36PM +0100, Oliver Neukum wrote:
> Am Samstag, 8. Dezember 2001 01:21 schrieb Greg KH:
> >
> > Yes, but it does so for a large number of devices that do not have
> > major:minor numbers assigned to them (like all of the USB digital
> > cameras that gphoto supports.)
>
On Sat, 8 Dec 2001, David Brownell wrote:
> > I am using such a workaround for Nomad II and it is fine.
> > hotplugger checks that the device is Nomad II and then unprotects it.
>
> So you really don't care which Nomad you download the
> MP3s to?? I'm surprised.
Hard to believe, considering
> Consider a system with multiple removable ATA HDDs. If the bays connect
> to the host system via USB<->ATA bridges, the serial number that the
> host sees will be that of the bay, not the HDD itself.
Which is as it should be.
> Using volume labels or UUIDs in /etc/fstab is much safer. It work
> > > If the two devices have same VendorId:ProductID it should not matter.
> > > They will get their sequence numbers in the order they were plugged-in.
> >
> > But as I said, that's not enough. It makes a huge difference which
> > device is which.
>
> Well, I think it does not as long as devi
Am Sonntag, 9. Dezember 2001 01:14 schrieb Jacek Pliszka:
> On Sat, 8 Dec 2001, David Brownell wrote:
> > Well for starters, the notion that those two characteristics are enough
> > to address the problem. Consider that I might have two USB disk drives
> > (or cameras) of the same make/model, and
Am Sonntag, 9. Dezember 2001 01:21 schrieb David Brownell:
> > > What I was getting at is that assigning names at the "logical"
> > > layer, where function matters, changes in a hotpluggable world.
> > >
> > > Assigning those function-based names in the kernel is part
> > > of the problem: it can
Jacek Pliszka wrote:
> You still may have volumes with the same labels.
True, but at least that would be because of bad naming policy by the
user, rather than because of hardware failure, pressing the reset
button, plugging the cable in the wrong port...
I guess my point is that we should fo
Quoting David Brownell <[EMAIL PROTECTED]>:
> > > Well for starters, the notion that those two characteristics are enough
> > > to address the problem. Consider that I might have two USB disk drives
> > > (or cameras) of the same make/model, and they might get connected in any
> > > order.
> >
On Sat, 8 Dec 2001, David Brownell wrote:
> > If the two devices have same VendorId:ProductID it should not matter.
> > They will get their sequence numbers in the order they were plugged-in.
>
> But as I said, that's not enough. It makes a huge difference which
> device is which.
Well, I thin
> > Well for starters, the notion that those two characteristics are enough
> > to address the problem. Consider that I might have two USB disk drives
> > (or cameras) of the same make/model, and they might get connected in any
> > order.
>
> If the two devices have same VendorId:ProductID it
> > What I was getting at is that assigning names at the "logical"
> > layer, where function matters, changes in a hotpluggable world.
> >
> > Assigning those function-based names in the kernel is part
> > of the problem: it can maybe make a decent first guess,
> > but before the device is advert
On Sat, 8 Dec 2001, Mark McClelland wrote:
> Using volume labels or UUIDs in /etc/fstab is much safer. It works with
> everything except the root fs (could be fixed in 2.5, I suppose) and
> swap devices (impossible w/o changing the format).
You still may have volumes with the same labels.
Reg
On Sat, 8 Dec 2001, David Brownell wrote:
> Well for starters, the notion that those two characteristics are enough
> to address the problem. Consider that I might have two USB disk drives
> (or cameras) of the same make/model, and they might get connected in any
> order.
If the two devices h
Oliver Neukum wrote:
>>But permanent changes are stored in the fs, _somewhere_; be it in a text
>>file, or a device node. /etc/fstab has some virtues; yes?
>>
>Yes, but permanent storage needs a way to identify devices across reboot,
>preferably a stable name. That is not there.
>
Ideally, we s
> > > What is the goal here? It appears as if we are trying to arrive at
> > > some point where we have capabilities similar to automounting,
> > > modprobing, /etc/fstab, and pinch of devfs thrown in.
> >
> > IMHO this should be the ultimate goal.
>
> Only for mountable devices. When someone c
> What I was getting at is that assigning names at the "logical"
> layer, where function matters, changes in a hotpluggable world.
>
> Assigning those function-based names in the kernel is part
> of the problem: it can maybe make a decent first guess,
> but before the device is advertised to the
> > "You can have Fast, Cheap or Reliable; Pick any two."
> > Are we trying to get all three?
I'd be content with "Reliable", meaning secure+robust.
We're already fast; taking a bigger fraction of a second
will normally not be noticeable. Cheap -- we're talking
Linux here, right? So that set o
> > One complication for USB -- not shared with any of the more
> > traditional device models! -- is hotplugging. Devices can be,
> > and are, added/removed at any time. They can move around.
> > The primary policy hook for security is to name a device. But
> > hotplugging means those names can
> | And lose the ability to make permanent changes. Besides it won't lead us
> | anywhere if we start a design with a workaround. For example, the naive
> | approach has race conditions.
>
> But permanent changes are stored in the fs, _somewhere_; be it in a text
> file, or a device node. /etc/f
Am Samstag, 8. Dezember 2001 23:05 schrieb xavyer:
> On Sat, 8 Dec 2001, Oliver Neukum wrote:
> | > E.g. you put int the /etc/fstab
> | >
> | > /dev/phison1 /Cext2 noauto,owner 0 0
> | >
> | > and in the hotplugging script:
> | >
> | > detect what major minor it is, let's say /dev/sd
Am Samstag, 8. Dezember 2001 22:02 schrieb Jacek Pliszka:
> On Sat, 8 Dec 2001, Oliver Neukum wrote:
> > > What is wrong with this naive method?
> >
> > You are screwed as soon as somebody presses reset. This may even be
> > exploitable.
>
> If someone can press reset on your machine - there are h
On Sat, 8 Dec 2001, Oliver Neukum wrote:
> > What is wrong with this naive method?
>
> You are screwed as soon as somebody presses reset. This may even be
> exploitable.
If someone can press reset on your machine - there are hundreds
way in which you are screwed.
You may create:
/dev/tmpdevic
> E.g. you put int the /etc/fstab
>
> /dev/phison1 /Cext2 noauto,owner 0 0
>
> and in the hotplugging script:
>
> detect what major minor it is, let's say /dev/sdb1 and then
> ln -s /dev/sdb1 /dev/phison1
>
> (of course in reality there is a problem with more than one
> identical de
On Sat, 8 Dec 2001, Oliver Neukum wrote:
> > But you control hotplugging. You can check in the hotplugging
> > script whether device has given VendorId and ProductId and
> > then take the proper action e.g.:
> > -giving proper persmission to user
> > -mounting device with proper rights
> Simply
Am Samstag, 8. Dezember 2001 19:18 schrieb Jacek Pliszka:
> On Sat, 8 Dec 2001, David Brownell wrote:
> > One complication for USB -- not shared with any of the more
> > traditional device models! -- is hotplugging. Devices can be,
> > and are, added/removed at any time. They can move around.
>
> - Where else does Linux use user mode drivers?
> * Frame buffer access for performance: DRI, DRM.
> * Printers, mostly (nowadays) using a serial byte-stream
> model to less performance-sensitive rendering systems.
> * Scanners (SANE) using serial byte-stream models
On Sat, 8 Dec 2001, David Brownell wrote:
> One complication for USB -- not shared with any of the more
> traditional device models! -- is hotplugging. Devices can be,
> and are, added/removed at any time. They can move around.
> The primary policy hook for security is to name a device. But
>
> > In general, when the questions involve mapping hardware (as
> > exposed by "usbfs" :) to logical devices (as exposed by kernel
> > drivers, and in some cases by smart enough apps), or vice
> > versa, neither "usbfs" nor the kernel driver is currently enough.
>
> Then what is sufficient ?
The
Am Samstag, 8. Dezember 2001 15:29 schrieb David Brownell:
> > I don't know of anyone using the usbdevfs interface on devices that have
> > a kernel driver associated with it. Does anyone else?
>
> Well, it's the clean way to construct the device tree in userland.
> Parsing the "devices" file is
> Well, he still has a point. There are two subsystems with widly overlapping
> functions. I must say, I feel this is not good. Yet, I have no clue what to
> do. Any ideas ?
I think about security and device naming models here...
Hardware access is classically privileged, for all kinds of fine
> I don't know of anyone using the usbdevfs interface on devices that have
> a kernel driver associated with it. Does anyone else?
Well, it's the clean way to construct the device tree in userland.
Parsing the "devices" file is problematic in various cases.
In general, when the questions involv
53 matches
Mail list logo
