* module as seperate crate
@ 2020-11-29 17:36 Finn Behrens
2020-11-29 17:51 ` Miguel Ojeda
0 siblings, 1 reply; 7+ messages in thread
From: Finn Behrens @ 2020-11-29 17:36 UTC (permalink / raw)
To: rust-for-linux
Hi,
What is the reason for module being an extra crate? I would have to run
some generic setup code for kernel/printk, but as the module macro being
from an extra crate, I cannot easily run some code there. Should we
maybe move module into the kernel crate, to make this easier?
Finn
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: module as seperate crate
2020-11-29 17:36 module as seperate crate Finn Behrens
@ 2020-11-29 17:51 ` Miguel Ojeda
2020-11-29 17:54 ` Finn Behrens
0 siblings, 1 reply; 7+ messages in thread
From: Miguel Ojeda @ 2020-11-29 17:51 UTC (permalink / raw)
To: Finn Behrens; +Cc: rust-for-linux
On Sun, Nov 29, 2020 at 6:38 PM Finn Behrens <me@kloenk.de> wrote:
>
> What is the reason for module being an extra crate? I would have to run
> some generic setup code for kernel/printk, but as the module macro being
> from an extra crate, I cannot easily run some code there. Should we
> maybe move module into the kernel crate, to make this easier?
It is because it is a proc macro. Otherwise, if Rust supported proc
macros in the same crate, we could do it, yeah.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: module as seperate crate
2020-11-29 17:51 ` Miguel Ojeda
@ 2020-11-29 17:54 ` Finn Behrens
[not found] ` <d417fec0-c5c6-edda-796e-a861f5518eed@kloenk.de>
0 siblings, 1 reply; 7+ messages in thread
From: Finn Behrens @ 2020-11-29 17:54 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: rust-for-linux
Oh, I see the problem. Ok, will try some more on how to create a mutex
value.
I'm currently trying to implement pr_*.
As we cannot define stuff easily, I would create a set_pr_fmt macro,
which stores some fmt info globaly. This is where I would like to use a
mutex.
Finn
On 11/29/20 6:51 PM, Miguel Ojeda wrote:
> On Sun, Nov 29, 2020 at 6:38 PM Finn Behrens <me@kloenk.de> wrote:
>> What is the reason for module being an extra crate? I would have to run
>> some generic setup code for kernel/printk, but as the module macro being
>> from an extra crate, I cannot easily run some code there. Should we
>> maybe move module into the kernel crate, to make this easier?
> It is because it is a proc macro. Otherwise, if Rust supported proc
> macros in the same crate, we could do it, yeah.
>
> Cheers,
> Miguel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: module as seperate crate
[not found] ` <CANiq72negqN+2eOjieYW1Zas1ays3t3W-+wZisXjF9q=kob3yw@mail.gmail.com>
@ 2020-11-29 18:30 ` Finn Behrens
2020-12-09 23:20 ` Miguel Ojeda
0 siblings, 1 reply; 7+ messages in thread
From: Finn Behrens @ 2020-11-29 18:30 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: rust-for-linux
I create a static mut Mutex<&str> (or similar) to contain the pr_fmt
string. I cannot init the mutex in a const fn, and so I cannot create an
static mut value which already contains a mutex. So I have to call an
init_printk functions which creates this mutex. That's all what I'm doing.
Will try to get something working the following days, and then send a
patch. Mayebe easier to decide then.
Finn
On 11/29/20 7:26 PM, Miguel Ojeda wrote:
> On Sun, Nov 29, 2020 at 7:11 PM Finn Behrens <me@kloenk.de> wrote:
>> Found a way! proc_macro is just a tokenstream, which gets substituted.
>> So I can just write what I want there, and it works.
>>
>> I would start implementing a Mutex<T> type with const and non const
>> functions now.
> I am not sure I understand why you want the Mutex in the module crate
> -- the module crate is only used to generate boilerplate code that
> needs to go copy-pasted into every module.
>
> Cheers,
> Miguel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: module as seperate crate
2020-11-29 18:30 ` Finn Behrens
@ 2020-12-09 23:20 ` Miguel Ojeda
2020-12-12 23:48 ` Wedson Almeida Filho
0 siblings, 1 reply; 7+ messages in thread
From: Miguel Ojeda @ 2020-12-09 23:20 UTC (permalink / raw)
To: Finn Behrens; +Cc: rust-for-linux, Wedson Almeida Filho
On Sun, Nov 29, 2020 at 7:30 PM Finn Behrens <me@kloenk.de> wrote:
>
> I create a static mut Mutex<&str> (or similar) to contain the pr_fmt
> string. I cannot init the mutex in a const fn, and so I cannot create an
> static mut value which already contains a mutex. So I have to call an
> init_printk functions which creates this mutex. That's all what I'm doing.
>
> Will try to get something working the following days, and then send a
> patch. Mayebe easier to decide then.
This email is just to give Wedson an email thread to reply to. :-)
Cheers,
Miguel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: module as seperate crate
2020-12-09 23:20 ` Miguel Ojeda
@ 2020-12-12 23:48 ` Wedson Almeida Filho
2020-12-13 1:00 ` Miguel Ojeda
0 siblings, 1 reply; 7+ messages in thread
From: Wedson Almeida Filho @ 2020-12-12 23:48 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: Finn Behrens, rust-for-linux
Thank you, Miguel!
Finn,
I posted on your PR before, but I think this is a better forum for
this. IIUC, you are implementing the pr_* family of functions and you
need a mutex for that. If this is the case, I think using a mutex is
probably not the ideal solution because it precludes the functions
from being used in contexts where blocking the task is not allowed.
I've just uploaded[1] a WIP commit that contains a SpinLock, which is
probably a better choice. Also, if this is a one-time initialisation
sort of thing, we can probably use a more efficient synchronisation
primitive. If you could describe your needs in more detail we could
probably work something out.
(As for the SpinLock implementation, it also has a condition variable
that uses a generic `Guard`, so if you want to hook your mutex
implementation to this, it will automatically work with the condition
variable too.)
Cheers,
-Wedson
[1] Spin lock commit:
https://github.com/Rust-for-Linux/linux/commit/3a9b3137f6fd179df3dacb72d717f5f4b4d0a266
On Wed, 9 Dec 2020 at 23:20, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Sun, Nov 29, 2020 at 7:30 PM Finn Behrens <me@kloenk.de> wrote:
> >
> > I create a static mut Mutex<&str> (or similar) to contain the pr_fmt
> > string. I cannot init the mutex in a const fn, and so I cannot create an
> > static mut value which already contains a mutex. So I have to call an
> > init_printk functions which creates this mutex. That's all what I'm doing.
> >
> > Will try to get something working the following days, and then send a
> > patch. Mayebe easier to decide then.
>
> This email is just to give Wedson an email thread to reply to. :-)
>
> Cheers,
> Miguel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: module as seperate crate
2020-12-12 23:48 ` Wedson Almeida Filho
@ 2020-12-13 1:00 ` Miguel Ojeda
0 siblings, 0 replies; 7+ messages in thread
From: Miguel Ojeda @ 2020-12-13 1:00 UTC (permalink / raw)
To: Wedson Almeida Filho; +Cc: Finn Behrens, rust-for-linux
On Sun, Dec 13, 2020 at 12:48 AM Wedson Almeida Filho
<wedsonaf@google.com> wrote:
>
> Thank you, Miguel!
You're welcome!
> Finn,
>
> I posted on your PR before, but I think this is a better forum for
> this. IIUC, you are implementing the pr_* family of functions and you
> need a mutex for that. If this is the case, I think using a mutex is
> probably not the ideal solution because it precludes the functions
> from being used in contexts where blocking the task is not allowed.
Agreed. However, I think I am not following why a mutex is needed for
implementing the printing functions. `printk()` is designed to be able
to be called from any context and formatting should be done on a local
buffer.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-12-13 1:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-29 17:36 module as seperate crate Finn Behrens
2020-11-29 17:51 ` Miguel Ojeda
2020-11-29 17:54 ` Finn Behrens
[not found] ` <d417fec0-c5c6-edda-796e-a861f5518eed@kloenk.de>
[not found] ` <CANiq72negqN+2eOjieYW1Zas1ays3t3W-+wZisXjF9q=kob3yw@mail.gmail.com>
2020-11-29 18:30 ` Finn Behrens
2020-12-09 23:20 ` Miguel Ojeda
2020-12-12 23:48 ` Wedson Almeida Filho
2020-12-13 1:00 ` Miguel Ojeda
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).