idea: vnconfig '-l' ?
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?
- add some kind of global 'STATUS' ioctl to sys/dev/disk/vn/vn.c
- have vnconfig dump this
- add some kind of per-vn 'STATUS' ioctl to sys/dev/disk/vn/vn.c
- 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,
#2 Updated by c.turner over 10 years ago
yeah - I guess not having to worry about it at all is one way around
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.
#3 Updated by dillon over 10 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.
#5 Updated by dillon over 10 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?)
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.
#7 Updated by dillon over 10 years ago
:Ah, I see. Can't we have a fdesc associated with a vnode which [am]time =
:then get updated?
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.
#10 Updated by c.turner about 8 years ago
actually, I committed a patch for this (or at least submitted one that
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
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
Antonio Huete Jimenez (via DragonFly issue tracker) wrote:
> Antonio Huete Jimenez <firstname.lastname@example.org> added the comment:
> Now that DFBSD has devfs, can this be closed?
> DragonFly issue tracker <email@example.com>