Date:	Mon, 06 Jul 2015 03:34:59 +0100
From:	jon <jon@...shouse.co.uk>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Valdis.Kletnieks@...edu, coreutils@....org,
	linux-kernel@...r.kernel.org
Subject: Re: Feature request, "create on mount" to create mount point
 directory on mount, implied remove on unmount

On Mon, 2015-07-06 at 02:08 +0100, Al Viro wrote:
> On Mon, Jul 06, 2015 at 12:35:48AM +0100, jon wrote:
> > > Anyway, the underlying model hasn't changed much since _way_ back; each
> > > thread of execution is a virtual machine of its own, with actual CPUs
> > > switched between those.
> > Ok, not sure I quite follow. What do you mean virtual machine  ? 

> Anything timesharing, starting with 7094 running CTSS.  Hypervisors allow to
> virtualize priveleged mode parts of processor; it's a different beast.
This was my point.  To me "virtual machine" is a modern term that
describes something running with a hypervisor.
My confusion is you are retrospectively applying it to time sharing.
I managed to find the article that first taught me about schedulers, the
1979 Byte article "Introduction to Multiprogrammig" 

https://archive.org/details/byte-magazine-1979-09

Searching for the pdf for the term "virtual" gives one result, not in
that article.

I remember "virtual memory" and even "virtual addressing" but I think
the term "virtual machine" is modern, maybe someone else knows, google
did not help me much trying to prove it one way or the other.

> It's considerably older than hypervisors (and both are much older than
> x86).
Yes it is, but it was not called "virtual machine" at the time in anything I personally read.

> I was not aware that the parent
> > could see file descriptors created by the child, is this always true or
> > only true if the parent and child are explicitly a shared memory
> > process.
> 
> It is true if and only if clone(2) gets CLONE_FILES in its arguments.
> Sharing address space is controlled by CLONE_VM and these can be used
> independently; pthreads set both at the same time, but you can have shared
> descriptor table without shared memory and vice versa.  Most of the time
> you use shared descriptor tables, you want shared memory as well, but
> it's not universally true.
I mainly use fork(), file descriptors are copied (forward) but memory
not shared.


> > Ok, I follow that :-) But logically it must be done with two functions
> > or handlers or something, so I would assume that my proposed "remove
> > mount directory" would simply hang off whatever call truly discards the
> > file system from the kernel.
> 
> Er...  _Which_ mount directory would you have removed
The one that was passed as "target" in the call ? I assume the kernel
stores that ?
int mount(const char *source, const char *target,
 

>  (and what's to
> guarantee that all filesystems it had been mounted on are still alive
> when the last mount goes away)?
?The same rules that would be in play if it was cross mounted in some
other way, or am I being dumb here?

I assume Linux will not let me unmount a mount point from lower in the
directory tree. I've not tried in living memory so lets give it a
go ....

root@...spc:/# mkdir mounttest
root@...spc:/# cd mounttest/
root@...spc:/mounttest# mkdir firstmount
root@...spc:/mounttest# mount /dev/sdb1 /mounttest/firstmount
root@...spc:/mounttest# cd firstmount/
root@...spc:/mounttest/firstmount# mkdir secondmount
root@...spc:/mounttest/firstmount# mount /dev/sdb1 /mounttest/firstmount/secondmount/
root@...spc:/mounttest/firstmount# cd ..
root@...spc:/mounttest# umount /mounttest/firstmount
umount: /mounttest/firstmount: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

It fails, as I expected.
 Also rmdir would fail if the mount point had was anything other than
empty, mkdir would fail if the mount point was already created.
I don't see how the kernel doing a pre mount mkdir and a post mount
rmdir would differ in outcome from user space performing the same
operations regardless of convoluted configuration was in use.
Like I said I dont use containers or Zen so can you show me a
(preferably simple) scenario that my proposal breaks.

I assume an entry in a table in the kernel is the source of the above
"device is busy" message, is this not also true if the name spaces
differ but the same file system is mounted in multiple places?

I would expect unmount <device> to unmount all mounted references to
that device and umount <mountpoint> to remove just that mountpoint or am
I miss remembering....



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists