Bug #721

idea: vnconfig '-l' ?

Added by c.turner about 7 years ago. Updated over 4 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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 this

or

- 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

History

#1 Updated by corecode about 7 years ago

We need device cloning :/ sigh... all our troubles would be gone![tm]

cheers
simon

#2 Updated by c.turner about 7 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

#3 Updated by dillon about 7 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
<>

#4 Updated by corecode about 7 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

#5 Updated by dillon about 7 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

#6 Updated by corecode about 7 years ago

Ah, I see. Can't we have a fdesc associated with a vnode which [am]time then get updated?

cheers
simon

#7 Updated by dillon about 7 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

#8 Updated by wa1ter about 7 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.

#9 Updated by tuxillo almost 5 years ago

Now that DFBSD has devfs, can this be closed?

#10 Updated by c.turner almost 5 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 <> added the comment:
>
> Now that DFBSD has devfs, can this be closed?
>
> _____________________________________________________
> DragonFly issue tracker <>
> <http://bugs.dragonflybsd.org/issue721>
> _____________________________________________________

Also available in: Atom PDF