Мне также удалось найти уникальное устройство в / dev / serial / by-id
. Я еще не пробовал перезагрузку, но файлы в этом каталоге были просто ссылками на соответствующий файл устройства ( ttyACM [0-9]
). «
Я использую Arch Linux на Raspberry Pi , но я наткнулся на них, просто выполнив find
для имен файлов, содержащих "Arduino". Мои программы на Python отлично работают, используя эти файлы в качестве устройств для чтения / записи данных в / из моих Arduinos (пока что два на одном Pi).
Глядя внутрь Linux v4.17, я думаю, мы можем сказать, что umount
на /
эквивалентно umount
на /..
. И /..
получает доступ к «верху [] кучи точек монтирования».
# stat -f / --format %T
ext2/ext3
# stat -f /.. --format %T
tmpfs
Такое непонятное поведение ..
, кажется, разрешено POSIX. В нем только говорится: «В особом случае в корневом каталоге точка -точка может относиться к самому корневому каталогу». (POSIX.1 -2017, раздел 4.13 «Разрешение пути» ).
Если вы хотите обобщить это и определить поведение, реализованное umount
на других точках монтирования, сравнение с ..
не работает так хорошо. Термин «верхняя часть кучи точек монтирования» по-прежнему применим, хотя и не звучит как очень формальное определение :).
https://elixir.bootlin.com/linux/v4.17/source/fs/namei.c
Посмотрите, где path_mountpoint()
вызывает follow_mount()
.
/**
* path_mountpoint - look up a path to be umounted
* @nd: lookup context
* @flags: lookup flags
* @path: pointer to container for result
*
* Look up the given name, but don't attempt to revalidate the last component.
* Returns 0 and "path" will be valid on success; Returns error otherwise.
*/
static int
path_mountpoint(struct nameidata *nd, unsigned flags, struct path *path)
{
const char *s = path_init(nd, flags);
int err;
if (IS_ERR(s))
return PTR_ERR(s);
while (!(err = link_path_walk(s, nd)) &&
(err = mountpoint_last(nd)) > 0) {
s = trailing_symlink(nd);
if (IS_ERR(s)) {
err = PTR_ERR(s);
break;
}
}
if (!err) {
*path = nd->path;
nd->path.mnt = NULL;
nd->path.dentry = NULL;
follow_mount(path);
}
terminate_walk(nd);
return err;
}
Комментарий для follow_mount()
звучал так, как будто он имел отношение к вопросу. И он упоминает follow_dotdot()
как основного пользователя, предложившего это направление расследования.
/*
* Skip to top of mountpoint pile in refwalk mode for follow_dotdot()
*/
static void follow_mount(struct path *path)
{
while (d_mountpoint(path->dentry)) {
struct vfsmount *mounted = lookup_mnt(path);
if (!mounted)
break;
dput(path->dentry);
mntput(path->mnt);
path->mnt = mounted;
path->dentry = dget(mounted->mnt_root);
}
}
static int follow_dotdot(struct nameidata *nd)
Я думал о том, как..
("dotdot" )может перемещаться от точки монтирования к своему родителю, например. /tmp/..
. Но я раньше не думал, что это может «перейти к [] вершине [] кучи точек монтирования». Это происходит даже в том случае, если верхнее монтирование не содержит исходный каталог /tmp
!