From: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
To: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: Linux-pm mailing list <linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: Re: pm_message_t becoming struct
Date: Fri, 25 Mar 2005 16:23:32 +0100 [thread overview]
Message-ID: <20050325152332.GA3738@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0503251004490.1094-100000-3WpdWqXrU/qjv4eRiOYp3g@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]
Hi!
> > static int foo_suspend(struct pci_dev *pdev, u32 state)
> >
> > . that's wrong. Now we have
> >
> > static int foo_suspend(struct pci_dev *pdev, pm_message_t state)
> >
> > , which is slightly better, but people still get it wrong, because
> > pm_message_t is compatible with u32. Oops. Obvious solution is to make
> > pm_message_t typedefed into struct, so people can't do the typing
> > wrong. This is kernel 101.
> >
> > What you would like to have is
> >
> > static int foo_suspend(struct pci_dev *pdev, struct pm_message *state)
> >
> > which I agree is marginally nicer to look at, but still does not
> > provide enough typechecking and [more importantly] there's no way in
> > hell we are doing second search and replace over all the drivers.
>
> Are you willing to go halfway? If we do something more like this:
>
> typedef struct {
> struct pm_message *m;
> } pm_message_t;
>
> then the code can pass pm_message_t's around with full type-checking and
> still retain the benefit of sending a pointer rather than a structure.
>
> Yes, it looks stupid. But it's a reasonable compromise that won't
I'm afraid it really looks stupid. [It actually has benefit that we
_could_ go over tree in future and change pm_message_t into struct
pm_message *.]
OTOH we would probably be stuck with this stupid-looking-thing
forever, and I'd really prefer to avoid that.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2005-03-25 15:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-25 10:11 pm_message_t becoming struct Pavel Machek
[not found] ` <20050325101149.GA1301-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
2005-03-25 10:56 ` Patrick Mochel
[not found] ` <Pine.LNX.4.50.0503250223490.28664-100000-x8k/2hhmB0w5etPau2IXcQ@public.gmane.org>
2005-03-25 11:17 ` Pavel Machek
[not found] ` <20050325111758.GC1297-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
2005-03-25 15:12 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.0503251004490.1094-100000-3WpdWqXrU/qjv4eRiOYp3g@public.gmane.org>
2005-03-25 15:23 ` Pavel Machek [this message]
[not found] ` <20050325152332.GA3738-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
2005-03-25 15:51 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050325152332.GA3738@elf.ucw.cz \
--to=pavel-+zi9xunit7i@public.gmane.org \
--cc=linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox