On Wed, 10 Mar 2010 11:53:43 +0900
Masao Uebayashi wrote:
[device node ownership and modes on devfs]
> Is it acceptable for you to do such things by some layering?
Anything else but "chown jkunz.users /dev/ttyU0" is awkward to me.
So what ever solution for this problem is introduced (udevd,
rc.sc
> The code providing DKWEDGE_METHOD_GPT already has the knowledge. I
> don't think that the knowledge has to move from there. All that dk(4)
> has to do is to match device-properties lists, and for that it can use
> the same library function as every other match routine will use.
What if you wan
> That's also my understanding, but since this system is also very simple,
> even a kernel implementation would probably be nice to do this, in
> which case users of such a system could add an entry in
> their /etc/fstab to mount the uuid fs under /dev/uuid/ ?
Yes. That's exactly same view with m
On Tue, 9 Mar 2010 22:52:17 -0500
Steven Bellovin wrote:
>
> On Mar 9, 2010, at 10:43 PM, Masao Uebayashi wrote:
>
> >> I think that Joerg's proposal doesn't prevent you from doing what you
> >> want, though I don't think it helps, either. He suggested that /dev/uuid
> >> and /dev/label just
> One of the problems is that such a long term user like you have to
> know the full detailed dmesg and analyze it. That doesn't meet my
> goals. Imagize admins hot-swap multiple disks/NICs on missiong
> critical servers.
And you have to disable configuration other PCI buses to prevent
unwanted
On Mar 9, 2010, at 10:43 PM, Masao Uebayashi wrote:
>> I think that Joerg's proposal doesn't prevent you from doing what you want,
>> though I don't think it helps, either. He suggested that /dev/uuid and
>> /dev/label just have symlinks to the usual device file, so no user-level
>> daemons w
> I think that Joerg's proposal doesn't prevent you from doing what you want,
> though I don't think it helps, either. He suggested that /dev/uuid and
> /dev/label just have symlinks to the usual device file, so no user-level
> daemons would be involved.
He said it has to be done in userland d
On Mar 9, 2010, at 4:45 PM, Thor Lancelot Simon wrote:
> On Tue, Mar 09, 2010 at 02:58:43PM -0500, Steven Bellovin wrote:
>>
>> On Mar 9, 2010, at 2:55 PM, Thor Lancelot Simon wrote:
>>
>>>
>>> That's a matter for the kernel to decide -- not one for some userspace
>>> program which could be ta
> I programm microcontrolers with a serial programmer. I use a serial
> connection to the target microcontroler for debugging. So I want to
> be able to read/write the serial port device node (e.g. /dev/tty03
> or /dev/ttyU0) directely. But I don't want other users grant access to
> my serial devic
> These two are traditionally a source of real problems for devfs or
> arrangements like it. I had an Irix system once where I wanted to be sure
> disks attached to the external scsi connectors -- used only for a
> tape drive -- couldn't be used.
>
> What a pain that was. Yet the internal disk sl
> I had to deal with every of those scenarios, and never could stand
> existing devfs implementations on my systems; I however previously
> participated to a thread about devfs with ideas and suggestions for a
> possibly less broken pipe-dream implementation, but it simply tought me
> how complex a
Heh, you want everything.
And all of you understand how difficult it's to implement a
full-featured filesystem? There are tradeoffs. My intent is to keep
simple and intuitive. I also assume NetBSD users are not stupid to
learn new things.
> - I want to present a subset of devices to a chrooted
> "More or less", because I don't have all the details. If you were to post
> the dmesg from your booting, I could give you the exact thing.
One of the problems is that such a long term user like you have to
know the full detailed dmesg and analyze it. That doesn't meet my
goals. Imagize admins
Quentin Garnier wrote:
On Tue, Mar 09, 2010 at 09:14:09PM +0100, Johnny Billquist wrote:
Quentin Garnier wrote:
[...]
My answer only intended to show that the device enumeration isn't
random, depending on if you add/remove other devices, which is what
Masao was claiming.
Your answer only say
On Tue, 9 Mar 2010 21:59:23 + (UTC)
chris...@astron.com (Christos Zoulas) wrote:
> In article <70f62c5e1003091104l20b98c5ex66842f01e6f17...@mail.gmail.com>,
> Masao Uebayashi wrote:
> >> Wow, that sucks. Not being able to change permissions (and less
> >> importantly,
> >> mv or rm the dev
I would like for MI drivers to be able to override pci(9), bus_space(9),
and bus_dma(9) behavior for the purpose of handling exceptions, managing
bus resources, creating test harnesses, and counting events.
Where pci(9), bus_space(9), and bus_dma(9) implementations are MD,
today, I would like to s
On Tue, Mar 09, 2010 at 09:59:23PM +, Christos Zoulas wrote:
>
> - I want to prevent access to the device completely by not providing a device
> node.
> - I want to preserve those changes across boots.
These two are traditionally a source of real problems for devfs or
arrangements like it.
In article <70f62c5e1003091104l20b98c5ex66842f01e6f17...@mail.gmail.com>,
Masao Uebayashi wrote:
>> Wow, that sucks. Not being able to change permissions (and less importantly,
>> mv or rm the device files) would definitely be a problem.
>
>Could you show me use cases how it sucks? I need more
On Mar 9, 2010, at 3:41 PM, Quentin Garnier wrote:
> On Tue, Mar 09, 2010 at 09:14:09PM +0100, Johnny Billquist wrote:
>> Quentin Garnier wrote:
> [...]
>> My answer only intended to show that the device enumeration isn't
>> random, depending on if you add/remove other devices, which is what
>> M
On Tue, Mar 09, 2010 at 02:58:43PM -0500, Steven Bellovin wrote:
>
> On Mar 9, 2010, at 2:55 PM, Thor Lancelot Simon wrote:
>
> >
> > That's a matter for the kernel to decide -- not one for some userspace
> > program which could be tampered with by any process running with euid 0.
> >
> > At le
On Tue, Mar 09, 2010 at 09:14:09PM +0100, Johnny Billquist wrote:
> Quentin Garnier wrote:
[...]
> My answer only intended to show that the device enumeration isn't
> random, depending on if you add/remove other devices, which is what
> Masao was claiming.
Your answer only says that device enumera
On Tue, Mar 09, 2010 at 03:52:09PM -0500, der Mouse wrote:
> >>> Lack of chmod/chown/etc in /dev would be a total showstopper (for
> >>> me, at the very least) for production use.
> >> Could you tell me the senario how it sucks?
> > [...example, plain user access to serial line...]
>
> That's one
>>> Lack of chmod/chown/etc in /dev would be a total showstopper (for
>>> me, at the very least) for production use.
>> Could you tell me the senario how it sucks?
> [...example, plain user access to serial line...]
That's one of the scenarios I've run into, though for me it's at least
as often be
On Wed, 10 Mar 2010 04:38:03 +0900
Masao Uebayashi wrote:
> Lack of chmod/chown/etc in /dev would
> > be a total showstopper (for me, at the very least) for production use.
> Could you tell me the senario how it sucks?
I programm microcontrolers with a serial programmer. I use a serial
connection
Quentin Garnier wrote:
On Tue, Mar 09, 2010 at 08:51:48PM +0100, Johnny Billquist wrote:
"More or less", because I don't have all the details. If you were to
post the dmesg from your booting, I could give you the exact thing.
Are you sure your USB disk shows up as sd? Looking at the config
file
On Tue, Mar 09, 2010 at 08:51:48PM +0100, Johnny Billquist wrote:
> "More or less", because I don't have all the details. If you were to
> post the dmesg from your booting, I could give you the exact thing.
>
> Are you sure your USB disk shows up as sd? Looking at the config
> file, I would have t
On Mar 9, 2010, at 2:55 PM, Thor Lancelot Simon wrote:
> On Tue, Mar 09, 2010 at 08:45:09PM +0100, Joerg Sonnenberger wrote:
>> On Tue, Mar 09, 2010 at 02:23:13PM -0500, Thor Lancelot Simon wrote:
>>> I want to be able to tell the kernel to mount a device reliably identified
>>> by some kind of u
On Tue, Mar 09, 2010 at 08:45:09PM +0100, Joerg Sonnenberger wrote:
> On Tue, Mar 09, 2010 at 02:23:13PM -0500, Thor Lancelot Simon wrote:
> > I want to be able to tell the kernel to mount a device reliably identified
> > by some kind of unique, symbolic name. I want to be able to load a list
> >
"More or less", because I don't have all the details. If you were to
post the dmesg from your booting, I could give you the exact thing.
Are you sure your USB disk shows up as sd? Looking at the config file, I
would have thought it would match wd.
If it is wd, then the config should have some
On Tue, Mar 09, 2010 at 02:23:13PM -0500, Thor Lancelot Simon wrote:
> I want to be able to tell the kernel to mount a device reliably identified
> by some kind of unique, symbolic name. I want to be able to load a list
> of permissible such names into the kernel while it's running insecure, and
>
> Of course, anyone who proposes to put it into NetBSD's main released
> tree without support for such things should be shouted down.
> Vociferously. And thoroughly. Lack of chmod/chown/etc in /dev would
> be a total showstopper (for me, at the very least) for production use.
Could you tell me t
>>> You need some kind of persistent state *somewhere*, to support
>>> chmod, chown, mv, rm, etc. Or are you proposing to break those?
>> My devfs doesn't do that complicate thing.
> Wow, that sucks. Not being able to change permissions (and less
> importantly, mv or rm the device files) would de
On Tue, Mar 09, 2010 at 12:57:49PM -0600, Eric Haszlakiewicz wrote:
>
> This is already a problem with dkctl.
I can disable dkctl and rely on the kernel's autodiscovery of wedges.
> And anyway, jacking around with the
> userspace daemon is unnecessarily complicated: if you have sufficient access
> Wow, that sucks. Not being able to change permissions (and less importantly,
> mv or rm the device files) would definitely be a problem.
Could you show me use cases how it sucks? I need more use cases.
Masao
On Tue, Mar 09, 2010 at 04:10:47PM +, Iain Hibbert wrote:
> On Tue, 9 Mar 2010, David Young wrote:
> > On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
> > > (I say "device" rather than disk because I know that Bluetooth controllers
> > > work this way - you can't get the BDADDR un
On Wed, Mar 10, 2010 at 02:01:56AM +0900, Masao Uebayashi wrote:
> > You need some kind of persistent state *somewhere*, to support chmod,
> > chown, mv, rm, etc. Or are you proposing to break those? That idea
> > strikes me as a pretty crippling regression.
>
> My devfs doesn't do that complica
On Tue, Mar 09, 2010 at 11:43:07AM -0500, Thor Lancelot Simon wrote:
> On Tue, Mar 09, 2010 at 04:25:06PM +0100, Joerg Sonnenberger wrote:
> >
> > I don't think it has to be or should be in the kernel. Basically,
> > /dev/dk3 gets created or is used by the kernel. A daemon is notified
> > (*cough*
On Wed, Mar 10, 2010 at 02:03:53AM +0900, Masao Uebayashi wrote:
> > I don't see a problem. Let the kernel read the partition table,
> > iterate over the partitions, extract properties from each partition,
> > try to match a dk to each partition by properties (e.g., guid(dk3)
> > == guid(partition
On Tue, Mar 09, 2010 at 06:34:54PM +, Iain Hibbert wrote:
> On Tue, 9 Mar 2010, Joerg Sonnenberger wrote:
> > > Sorry I got confused - in your method, what is dk3 needed for?
> >
> > It is still the device, the rest are just symlinks.
>
> do you propose to do away with sd0a then?
That's a ver
> It would help if you started by showing where your disk would be in the
> device tree.
I connect USB memory (sd(4)) at uhci0. Please tell me.
> Then I can tell you what (more or less) you need in your config file.
"More or less" doesn't meet my criteria. Consider mission critical
use cases.
On Tue, 9 Mar 2010, Joerg Sonnenberger wrote:
> On Tue, Mar 09, 2010 at 04:06:59PM +, Iain Hibbert wrote:
> > > I don't think it has to be or should be in the kernel. Basically,
> > > /dev/dk3 gets created or is used by the kernel. A daemon is notified
> > > (*cough* udevd) and that scans the
On Tue, Mar 09, 2010 at 11:50:41AM -0500, der Mouse wrote:
> > And now anyone who can jack around with the userspace daemon process
> > can cause you to mount a filesystem you didn't intend to mount.
>
> Anyone who can meddle with a root-run process can do a lot worse than
> that (to start with, m
> I don't see a problem. Let the kernel read the partition table,
> iterate over the partitions, extract properties from each partition,
> try to match a dk to each partition by properties (e.g., guid(dk3)
> == guid(partition 7 at sd0)). If there is a match, take the dk unit
> number from the mat
> You need some kind of persistent state *somewhere*, to support chmod,
> chown, mv, rm, etc. Or are you proposing to break those? That idea
> strikes me as a pretty crippling regression.
My devfs doesn't do that complicate thing. Mine is more or less procfs +
kauth.
Masao
--
Masao Uebayashi
> [...]. That makes devfs responsible to resolve confliction, which in
> turn leads to some configuration thing, which I definitely want to
> avoid.
You need some kind of persistent state *somewhere*, to support chmod,
chown, mv, rm, etc. Or are you proposing to break those? That idea
strikes m
> And now anyone who can jack around with the userspace daemon process
> can cause you to mount a filesystem you didn't intend to mount.
Anyone who can meddle with a root-run process can do a lot worse than
that (to start with, mounting that filesystem directly).
/~\ The ASCII
> And now anyone who can jack around with the userspace daemon process
> can cause you to mount a filesystem you didn't intend to mount.
>
> I think discovery of the identifiers used to mount devices needs to
> be in the kernel. We can do that already for RAIDframe and GPT; why
> back away from i
On Wed, Mar 10, 2010 at 01:24:40AM +0900, Masao Uebayashi wrote:
> > We don't need a second mechanism to handle dk(4), do we? If dk3 should
> > attach to the volume with GUID 60708090-a0b0-c0d0-e0f0-01020304050, let
> > the device properties say so:
> >
> >
> >
> > device-driver
> >
On Tue, Mar 09, 2010 at 04:25:06PM +0100, Joerg Sonnenberger wrote:
>
> I don't think it has to be or should be in the kernel. Basically,
> /dev/dk3 gets created or is used by the kernel. A daemon is notified
> (*cough* udevd) and that scans the device properties, finds the UUID and
> creates /dev
On Tue, Mar 09, 2010 at 04:06:59PM +, Iain Hibbert wrote:
> > I don't think it has to be or should be in the kernel. Basically,
> > /dev/dk3 gets created or is used by the kernel. A daemon is notified
> > (*cough* udevd) and that scans the device properties, finds the UUID and
> > creates /dev/
> > What if udevd is on /dev/uuid/2345324523453245 ?
>
> The boot loader has a separate mechanism to pass down what is booted
> from. That should be good enough for getting root mounted.
What do you mean? How can you mount / on /dev/uuid/2345324523453245?
Masao
--
Masao Uebayashi / Tombi Inc.
> We don't need a second mechanism to handle dk(4), do we? If dk3 should
> attach to the volume with GUID 60708090-a0b0-c0d0-e0f0-01020304050, let
> the device properties say so:
>
>
>
> device-driver
> dk
> device-unit
> 0x3
> guid
> 60708090-a0b0-c0
> I'd go further and say that we should be able to supply a set of device
> properties (such as drvctl -p prints) to the kernel. Let us match a
> device by its intrinsic properties (MAC address, serial number, and/or
> GUID), and set the unit number according to the device property.
Where do thos
On Tue, 9 Mar 2010, David Young wrote:
> On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
> > One thing that I think is problematic about trying to do that, is that you
> > might sometimes need to attach a device (allocate the unit number) in
> > order to discover its intrinsic proper
On Tue, 9 Mar 2010, Joerg Sonnenberger wrote:
> On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
> > I have never used wedges but, for the disk case, would it not be better to
> > make a method of configuring a dk in advance, so that whenever a disk
> > appears with the correct parame
On Tue, Mar 09, 2010 at 09:43:03AM -0600, David Young wrote:
> On Tue, Mar 09, 2010 at 04:25:06PM +0100, Joerg Sonnenberger wrote:
> > On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
> > > I have never used wedges but, for the disk case, would it not be better to
> > > make a method o
On Mar 9, 2010, at 10:25 AM, Joerg Sonnenberger wrote:
> On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
>> I have never used wedges but, for the disk case, would it not be better to
>> make a method of configuring a dk in advance, so that whenever a disk
>> appears with the correct
On Tue, Mar 09, 2010 at 04:25:06PM +0100, Joerg Sonnenberger wrote:
> On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
> > I have never used wedges but, for the disk case, would it not be better to
> > make a method of configuring a dk in advance, so that whenever a disk
> > appears wi
On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
> On Mon, 8 Mar 2010, David Young wrote:
>
> > On Mon, Mar 08, 2010 at 12:34:23PM -0700, Ted Lemon wrote:
> > > On Mar 8, 2010, at 12:47 AM, Masao Uebayashi wrote:
> > > > How do you write a kernel config which can always identify my US
On Mon, Mar 08, 2010 at 11:08:59PM +, Sad Clouds wrote:
> Hi, I've sent a similar message to netbsd-users@ list, but didn't get
> any responses, maybe somebody on tech-kern@ knows the answer?
>
> I've been looking at the following paper:
>
> "UBC: An Efficient Unified I/O and Memory Caching S
On Tue, Mar 09, 2010 at 08:09:57AM +, Iain Hibbert wrote:
> I have never used wedges but, for the disk case, would it not be better to
> make a method of configuring a dk in advance, so that whenever a disk
> appears with the correct parameters it will already be mapped to the dk
> you expect?
On Mon, 8 Mar 2010, David Young wrote:
> On Mon, Mar 08, 2010 at 12:34:23PM -0700, Ted Lemon wrote:
> > On Mar 8, 2010, at 12:47 AM, Masao Uebayashi wrote:
> > > How do you write a kernel config which can always identify my USB disk as
> > > sd0a, even if I plug random devices?
> >
> > You'd need
62 matches
Mail list logo
