Rust-for-linux archive on lore.kernel.org
 help / color / Atom feed
* 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, back to index

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

Rust-for-linux archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/rust-for-linux/0 rust-for-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 rust-for-linux rust-for-linux/ https://lore.kernel.org/rust-for-linux \
		rust-for-linux@vger.kernel.org
	public-inbox-index rust-for-linux

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.rust-for-linux


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git