* 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
[parent not found: <d417fec0-c5c6-edda-796e-a861f5518eed@kloenk.de>]
[parent not found: <CANiq72negqN+2eOjieYW1Zas1ays3t3W-+wZisXjF9q=kob3yw@mail.gmail.com>]
* 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).