Bug #721
closed
idea: vnconfig '-l' ?
0%
Description
Hello all,
I'm looking at using vnode disks for jails, image building, etc,
and would like to write a scripting interface against vnconfig
I'd prefer it to dynamically select the vn device, to keep from having
to do the housekeeping of statically configuring various vn devices, etc
but it seems there is no way to determine if a vn device file is in use
without actually trying to attach it (which I suppose is one way to do it).
For now, I'll probably just do the static mapping, but if I were to
investigate some creating some kind of '-l' (list) support for vnconfig,
what would be the best way to approach it?
thinking either:
- add some kind of global 'STATUS' ioctl to sys/dev/disk/vn/vn.c
- have vnconfig dump thisor
- add some kind of per-vn 'STATUS' ioctl to sys/dev/disk/vn/vn.c
(naming suggestion?)
- have vnconfig iterate over a glob on /dev/vn*, checking this IOCTL
(or alternately, files of appropriate major/minor type)or some kind of combination between these
but perhaps there is some other kernel structure that could just be
dumped somehow without the ioctl.. forgive me for not researching how
this works too thoroughly - just a quick idea+scan, that may not bear
fruit, just throwing it out there..
Thanks in advance,
- Chris
Updated by corecode over 17 years ago
We need device cloning :/ sigh... all our troubles would be gone![tm]
cheers
simon
Updated by c.turner over 17 years ago
yeah - I guess not having to worry about it at all is one way around
it
right now, thinking simple though - not trying to get too distracted
noodling around on it .. might investigate this over time though..
also - does everything on submit@ become a 'bug' - if so I'll stay to
users / kernel for these kinds of questions, at least until I have a
patch of course.
Thanks,
- Chris
Updated by dillon over 17 years ago
What we really need is devfs. Device cloning itself is really easy, but
to do it right we want a direct file descriptor device interface so
the device can be assigned to the (private) file pointer instead of to
the (shared) vnode. devfs is needed because when we bypass the vnode
the access and modified times will no longer get updated for devices
in a normal UFS based /dev filesystem.
-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by corecode over 17 years ago
would we care about these times? I mean, would we really care? On devfs, we'd lose this information on reboot as well. Or we "simply" add a sidechannel to update a [am]time on fdesc access (maybe that would fix my mmap time issue?)
cheers
simon
Updated by dillon over 17 years ago
:would we care about these times? I mean, would we really care? On dev=
:fs, we'd lose this information on reboot as well. Or we "simply" add a s=
:idechannel to update a [am]time on fdesc access (maybe that would fix my =
:mmap time issue?)
:
:cheers
: simon
We want things like 'w' to properly report the idle time for tty's.I don't think any of it needs to survive a reboot.-Matt
Updated by corecode over 17 years ago
Ah, I see. Can't we have a fdesc associated with a vnode which [am]time then get updated?
cheers
simon
Updated by dillon over 17 years ago
:Ah, I see. Can't we have a fdesc associated with a vnode which [am]time =
:then get updated?
:
:cheers
: simon
We already have shortcuts for the fdesc for devices which deal with
atime updates, but it's really a big mess. The only real solution
is devfs. We'll need devfs in the next year (2.1-2.2ish time frame)
anyhow because it is rather inconvenient to have to create large
matrixes of device nodes for disk slice/partition with the new
partitioning support schemes.-Matt
Updated by wa1ter over 17 years ago
Have you looked at udev? It's all done in userland so I'm guessing there
is nothing linux-specific about it. It works well for me, but the config
files are a nightmare.
Updated by tuxillo over 15 years ago
Now that DFBSD has devfs, can this be closed?
Updated by c.turner over 15 years ago
actually, I committed a patch for this (or at least submitted one that
was committed)
in around the 1.10 days -
didn't get back to closing it. my apologies.
with that in mind, I'm waaay behind on dragonfly testing/coding -
not sure if it still works w/devfs, though my assumption is that
it would..
think the feature is still useful & shouldn't be removed - unless devfs
removes vn devices after use..
will close in 1d - need password reset email & perhaps
there are other comments
Thanks,
- Chris
Antonio Huete Jimenez (via DragonFly issue tracker) wrote:
Antonio Huete Jimenez <tuxillo@quantumachine.net> added the comment:
Now that DFBSD has devfs, can this be closed?
_____________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue721>
_____________________________________________