Re: Call for Foundation-supported Project Ideas
- Reply: Gleb Popov : "Re: Call for Foundation-supported Project Ideas"
- In reply to: Joseph Mingrone : "Call for Foundation-supported Project Ideas"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 24 Nov 2021 11:09:45 UTC
(1) The device drivers are required to be "root" to implement them . Instead of ONLY this , the following steps may be performed : If the "user" ( being non-"root" ) attaches a device to the computer , the OS looks at a "user" space directory ( imitation of system-wise directory but in the "user" space ) if there is a driver for the device in that directory , it loads and uses it . If there is not any device driver for the device in "user" directory , it looks into the system directory . If there is one , it loads and uses it , else it gives an error message . To manage such "user" space devices , the OS needs to have the ability to look at the "user" space . This may be complemented by removing device drivers from the base system , and making them , let's say , ports or packages . The root loads the necessary ones from the system directories , but the "user" may have the ability to load them from her or his directories . Another important problem is mounting of hard disks connected through a USB port or a hot-pluggable port . Such connections ( excluding if DOS or NTFS ones are permitted implicitly ) require a "root" mount . There is an idea "Use sudo or other super user programs for "allowance" of "root" user" . In my life , I never could understand "How is it possible to manage to protect the security of a system by using such a facility from the "user" space ? " Is it not possible to allow the user to use a mount command for such non-DOS or non-NTFS devices ? Why is it necessary to have a fear about such mounting ? Please do NOT forget that the computer is available to the user PHYSICALLY . He ( let's assume he may use violence ) can destroy , crash , burn , ... , etc. , the computer PHYSICALLY . Such a possibility is not considered , but an innocent "user" space mount is assumed to be harmful . (2) Device definitions are stored as C program data or constant values . Make these as configuration files with ( names which can be generated from the recognized device parameters ) and loaded in run time when it is needed . In that way it will be possible to introduce new device definitions/descriptions/drivers only by copying its device description into the relevant directory whether it is "root" or "user" directory . Mehmet Erol Sanliturk On Wed, Nov 24, 2021 at 1:42 AM Joseph Mingrone <email@example.com> wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > firstname.lastname@example.org. > > -- > Joe (with Foundation hat on) > >