William Hubbs posted on Sun, 13 Oct 2013 14:32:32 -0500 as excerpted:
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselay
Patrick McLean wrote:
This is not true. Bind mounts can be performed on a single file, and
bind mounts are part of mount namespaces. Granted the target file _must_
exist (it could be a dead symlink, or a symlink to /dev/null) before
performing the bind mount.
Well that's even better then. :-)
On Mon, 14 Oct 2013 15:50:36 -0400
Rich Freeman wrote:
> On Mon, Oct 14, 2013 at 2:58 PM, David Leverton
> wrote:
> >
> > If only someone would invent some sort of kernel feature that could
> > make the name "/etc/mtab" refer to different files in different
> > processes
> >
>
> However, FW
I haven't spent much time on beets lately. Current version in tree is 1.1.0,
upstream is at 1.3.1. I have the ebuild more or less ready, but it still needs
testing/cleanups before I'd be willing to commit to tree. I would *really*
appreciate someone taking the package (and several deps, see end of
Mike Gilbert wrote:
This is a horrible example. /etc/resolv.conf is a configuration file
for code that lives entirely in userspace. Of course it makes no sense
to shove that into the kernel.
My point is that it's silly to have a hard-coded special case in the
kernel for mtab, especially if it
On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
wrote:
> So to work around that limitation we insist that everyone change how their
> systems are set up, and still have to reintroduce mtab under a different
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't*
> contain every
On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
wrote:
> Rich Freeman wrote:
>>
>> However, FWIW, linux namespaces cannot be used to have only a single
>> file appear differently to different processes. Mount namespaces can
>> only operate at the directory level.
>
>
> So to work around that limi
Rich Freeman wrote:
However, FWIW, linux namespaces cannot be used to have only a single
file appear differently to different processes. Mount namespaces can
only operate at the directory level.
So to work around that limitation we insist that everyone change how
their systems are set up, and
On Mon, Oct 14, 2013 at 2:58 PM, David Leverton
wrote:
>
> If only someone would invent some sort of kernel feature that could make the
> name "/etc/mtab" refer to different files in different processes
>
Well, the symlink seems like the simpler solution to be honest. I
mean, instead of havi
On 10/14/2013 01:24 PM, Rich Freeman wrote:
> Systemd lets you configure daemons to have restricted access to the
> filesystem as well - either read-only, or not at all - by directory.
> I assume it just clones the mount namespace, and then sets up
> bind-mounts to implement this before dropping ro
Rich Freeman wrote:
[...] and the point that many things
break in namespaces without the symlink, since /etc/mtab does not
reflect the state of the namespace. The latter in particular seems
like a pretty fundamental limitation - the very concept of /etc/mtab
is that mounts are global, and the de
On Mon, Oct 14, 2013 at 1:01 PM, Richard Yao wrote:
>
> 1. What are mount namespaces? How do they integrate with the kernel?
> 2. What does systemd do with them? What does systemd's use of them
> provide to users?
>
> Saying to google "per-process namespaces" does not really answer that.
> Per-pro
On Mon, Oct 14, 2013 at 12:47:08PM -0400, Richard Yao wrote:
*snip*
> Both of which are correct. That being said, I am not against making
> changes, but given that this is on the list, I would like to someone to
> provide a technical justification. Some key questions that justification
> should a
On 10/14/2013 12:34 PM, William Hubbs wrote:
> On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote:
>> On 10/14/2013 10:11 AM, Rich Freeman wrote:
>>> On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote:
The Linux kernel also supports far more architectures than we do. That
does
On 10/14/2013 10:46 AM, Richard Yao wrote:
> My main concern is that some of the configure flags being proposed could
> make packages that worked on Gentoo FreeBSD stop working there. I am not
> making changes, but I think that there should be some benefit and that
> care should be taken not to bre
On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote:
> On 10/14/2013 10:11 AM, Rich Freeman wrote:
> > On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote:
> >> The Linux kernel also supports far more architectures than we do. That
> >> does not mean that we must support them too.
> >>
> >
On Mon, Oct 14, 2013 at 10:00:03AM +0400, Peter Volkov wrote:
> В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].
> >
> > Are there any remaining concerns about doing this?
>
> The onl
On 10/14/2013 10:11 AM, Rich Freeman wrote:
> On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote:
>> The Linux kernel also supports far more architectures than we do. That does
>> not mean that we must support them too.
>>
>> With that said, how does changing things benefit/affect users, especial
On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote:
> The Linux kernel also supports far more architectures than we do. That does
> not mean that we must support them too.
>
> With that said, how does changing things benefit/affect users, especially
> non-systemd users?
Better support for names
The Linux kernel also supports far more architectures than we do. That does not
mean that we must support them too.
With that said, how does changing things benefit/affect users, especially
non-systemd users?
On Oct 14, 2013, at 9:36 AM, Michał Górny wrote:
> Dnia 2013-10-14, o godz. 09:26:43
Dnia 2013-10-14, o godz. 09:26:43
Richard Yao napisał(a):
> On Oct 14, 2013, at 9:19 AM, Rich Freeman wrote:
>
> > On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot wrote:
> >> I don't see a compelling case being made for why we should make this
> >> change apart from "all the other distros are do
On Oct 14, 2013, at 9:19 AM, Rich Freeman wrote:
> On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot wrote:
>> I don't see a compelling case being made for why we should make this
>> change apart from "all the other distros are doing it", and quite a
>> few reasons why we shouldn't. I'm open to bein
That is my impression as well.
With that said, the behavior is currently the same between our FreeBSD and
Linux variants. This change would break that.
On Oct 14, 2013, at 7:59 AM, Ben de Groot wrote:
> On 14 October 2013 03:32, William Hubbs wrote:
>> All,
>>
>> from what I'm seeing, we sho
On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot wrote:
> I don't see a compelling case being made for why we should make this
> change apart from "all the other distros are doing it", and quite a
> few reasons why we shouldn't. I'm open to being convinced, so please
> tell me why this is good for Ge
On 14 October 2013 03:32, William Hubbs wrote:
> All,
>
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselayout create
> thi
On Mon, Oct 14, 2013 at 12:42 AM, yac wrote:
>
> Curiously I don't see any difference on my gentoo box, which I think I
> should see but I'm not sure.
On mine the main difference seems to be bind mounts. In /etc/mtab the
bind mount "device" is the directory that is being bind-mounted. In
/proc/
On 14-10-2013 10:00:03 +0400, Peter Volkov wrote:
> В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].
> >
> > Are there any remaining concerns about doing this?
>
> The only concern I
27 matches
Mail list logo
