Exposing semaphores

Exposing semaphores

[Carlos]

Hello to all,

I recently began assessing what functionality from the kernel is missing
for implementing a basic scull driver.

Semaphores are the first missing primitive that caught my attention, and
being such an important part of the kernel itself, I will make exposing
this functionality my first priority instead.

It should be pretty straightforward, following the stablished convention of
leveraging the kernel API.

Any comments before I dig in?

Re: Exposing semaphores

[Alex Gaynor]

It sounds like you already identified it, but yup, that'd be my major
piece of advice, follow the conventions and traits use in the other
sync/ locking types:
https://github.com/Rust-for-Linux/linux/tree/rust/rust/kernel/sync

Glad to hear you're already diving into scull!

Cheers,
Alex


On Mon, Apr 26, 2021 at 8:02 PM Carlos <carloscarral13@gmail.com> wrote:
>
> Hello to all,
>
> I recently began assessing what functionality from the kernel is missing
> for implementing a basic scull driver.
>
> Semaphores are the first missing primitive that caught my attention, and
> being such an important part of the kernel itself, I will make exposing
> this functionality my first priority instead.
>
> It should be pretty straightforward, following the stablished convention of
> leveraging the kernel API.
>
> Any comments before I dig in?
>
>
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.

Re: Exposing semaphores

[Wedson Almeida Filho]

On Mon, Apr 26, 2021 at 07:02:07PM -0500, Carlos wrote:
> Semaphores are the first missing primitive that caught my attention, and
> being such an important part of the kernel itself, I will make exposing
> this functionality my first priority instead.

If the semaphores are used only for mutual exclusion, then you may want to just
use a mutex or spinlock that are already there. But that's only if you're
primarily interested in getting a rust scull to work first.

If you actually want to implement semaphores, go for it!

Re: Exposing semaphores

[Samantha Miller]

I don't think this sent last time, but sorry for the spam if it did

For my research project writing a safe Rust file system in the kernel,
I implemented RwLock as a wrapper around the kernel semaphore.
I'm not sure if it'll be exactly what you want, but feel free to use it as a
reference or more. The RwLock is here:
https://gitlab.cs.washington.edu/sm237/bento/-/blob/master/bento/rust/src/std/sync/rwlock.rs.

You can do a similar thing for a spinlock wrapper around the kernel
spinlock, I believe.

Re: Exposing semaphores

[Sven Van Asbroeck]

On Mon, Apr 26, 2021 at 8:13 PM Wedson Almeida Filho
<wedsonaf@google.com> wrote:
>
> If the semaphores are used only for mutual exclusion, then you may want to just
> use a mutex or spinlock that are already there. But that's only if you're
> primarily interested in getting a rust scull to work first.

(My apologies for not reading Wedson's message before hitting Reply)

Re: Exposing semaphores

[Sven Van Asbroeck]

Hi Carlos,

On Mon, Apr 26, 2021 at 8:02 PM Carlos <carloscarral13@gmail.com> wrote:
>
> I recently began assessing what functionality from the kernel is missing
> for implementing a basic scull driver.
>
> Semaphores are the first missing primitive that caught my attention, and
> being such an important part of the kernel itself, I will make exposing
> this functionality my first priority instead.

Isn't scull's semaphore used exclusively in mutex mode, i.e.
initialized using init_MUTEX?

If so, prefer "struct mutex" instead. At the time scull was written
(over 15 years ago) it did not yet exist.
A Rust-for-Linux abstraction is already available:
https://github.com/Rust-for-Linux/linux/blob/rust/rust/kernel/sync/mutex.rs

This is before my time, but I believe that the use of "bare" struct
semaphores in drivers used to be a common anti-pattern, often
resulting in buggy code and/or performance issues - most semaphores
have been replaced by conceptually safer, higher-level primitives, and
today one needs a valid excuse to use them in new or even refactored
driver code. But I do not know the full story.

Sven

Re: Exposing semaphores

[Greg KH]

On Tue, Apr 27, 2021 at 06:18:52AM -0400, Sven Van Asbroeck wrote:
> Hi Carlos,
> 
> On Mon, Apr 26, 2021 at 8:02 PM Carlos <carloscarral13@gmail.com> wrote:
> >
> > I recently began assessing what functionality from the kernel is missing
> > for implementing a basic scull driver.
> >
> > Semaphores are the first missing primitive that caught my attention, and
> > being such an important part of the kernel itself, I will make exposing
> > this functionality my first priority instead.
> 
> Isn't scull's semaphore used exclusively in mutex mode, i.e.
> initialized using init_MUTEX?
> 
> If so, prefer "struct mutex" instead. At the time scull was written
> (over 15 years ago) it did not yet exist.
> A Rust-for-Linux abstraction is already available:
> https://github.com/Rust-for-Linux/linux/blob/rust/rust/kernel/sync/mutex.rs
> 
> This is before my time, but I believe that the use of "bare" struct
> semaphores in drivers used to be a common anti-pattern, often
> resulting in buggy code and/or performance issues - most semaphores
> have been replaced by conceptually safer, higher-level primitives, and
> today one needs a valid excuse to use them in new or even refactored
> driver code. But I do not know the full story.

I agree, never try to ab-use a semaphore in the way we did it in the
book, that is not a good "pattern" to follow for the majority of kernel
drivers.

A simple mutex should be all that is necessary.

But also, while the CUSE driver has a lot of history, it really was only
created as an example to show how things could work, it isn't all that
useful in the real world :)

thanks,

greg k-h