From: Jacob Moody <firstname.lastname@example.org> To: email@example.com Subject: Re: [9front] [PATCH] Unmount to remove sharp devices. Date: Thu, 5 May 2022 10:07:19 -0600 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <7046F359DC6A29F1E24602BD744BC722@musolino.id.au> On 5/4/22 19:59, Alex Musolino wrote: > Did you consider implementing this with two commands (e.g. 'drop' and > 'permit') on the /dev/drivers file itself? That would make it just as > easy to do this kind of stuff from a script/program without having to > craft a namespace file. > > Obviously you'd have to have the #c device available until you're > finished "dropping" and "permitting" things, but perhaps that's not > really a problem. I think this is an excellent idea! The logic for doing permit within the kernel is much easier, as we already have an array of all current devices. I had started implementing a permit(1) and permit command for namespace files and that necessitated reading /dev/drivers to get a full list of current devices. While not a lot of code to do it, it felt like I shouldn't have to do the inversion myself from userspace. Unless others feel strongly about implementing device removal through unmount I am going to plan to change the implementation to do this instead. Also from my understanding, dropping #c in practice shouldn't be an issue, once you have a fd to #c/drivers, you can block #c and the fd will still accept further writes. You may not be able to reopen to #c/drivers file after closing that fd, but that seems completely reasonable to me. Thanks, moody
next prev parent reply other threads:[~2022-05-05 16:11 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-04 14:09 Jacob Moody 2022-05-04 15:05 ` ori 2022-05-04 15:31 ` ori 2022-05-04 16:15 ` Stanley Lieber 2022-05-04 17:41 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-05-04 17:55 ` Jacob Moody 2022-05-05 1:59 ` Alex Musolino 2022-05-05 16:07 ` Jacob Moody [this message] 2022-05-08 2:55 ` Jacob Moody 2022-05-11 14:47 ` Jacob Moody 2022-05-11 16:11 ` Stanley Lieber 2022-05-12 4:29 ` Jacob Moody 2022-05-12 3:18 ` ori 2022-05-12 5:10 ` Jacob Moody 2022-05-12 14:21 ` ori 2022-05-23 5:42 ` Jacob Moody 2022-05-23 17:06 ` cinap_lenrek 2022-05-23 17:37 ` Jacob Moody 2022-05-25 19:03 ` Jacob Moody 2022-05-25 20:53 ` hiro 2022-05-25 21:20 ` Jacob Moody 2022-05-26 5:55 ` Jacob Moody 2022-05-26 23:36 ` unobe 2022-05-27 0:33 ` Jacob Moody 2022-05-27 3:25 ` unobe 2022-05-26 3:13 ` ori 2022-05-27 1:11 ` Lyndon Nerenberg (VE7TFX/VE6BBM) 2022-05-27 2:25 ` Frank D. Engel, Jr.
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [9front] [PATCH] Unmount to remove sharp devices.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).