From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14097 invoked from network); 5 May 2022 16:11:19 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 5 May 2022 16:11:19 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Thu May 5 12:09:33 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1651766969; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Csqf22QKMtzZh9WwisRK/1xOUF9Cmjhz3zYsN6w8gXQ=; b=SKh1vJKfKv2xVnx4WXq9WQfwO9gnZntJ+aDpybiqX7qBF3g6/bOV2K0H3szu5ZsaUQ7XDS Dq7wMIsU0Ib3QWCUZIe8HUUM8oOFzq2rNSIUgZMNv12O+BLH1omOo5VAp2Cy4/ZP6l6+SH zC/izC10b5gmmpec4o/59/RSTAzqZSU= Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id b4cf2b95 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Thu, 5 May 2022 11:09:29 -0500 (CDT) Message-ID: Date: Thu, 5 May 2022 10:07:19 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: 9front@9front.org References: <7046F359DC6A29F1E24602BD744BC722@musolino.id.au> From: Jacob Moody In-Reply-To: <7046F359DC6A29F1E24602BD744BC722@musolino.id.au> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: asynchronous managed STM backend Subject: Re: [9front] [PATCH] Unmount to remove sharp devices. Reply-To: 9front@9front.org Precedence: bulk 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