From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [patch 1/8] Processor degredation support.
Date: Wed, 28 Mar 2007 08:54:43 +0200 [thread overview]
Message-ID: <20070328065443.GA8146@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <20070327213529.GB5842@ucw.cz>
> > +++ linux-2.6/drivers/s390/char/sclp_confmgm.c
>
> Can we get less cyptic name?
Would you like to see sclp_configuration_management.c?
> > +static void sclp_conf_receiver_fn(struct evbuf_header *evbuf)
> > +{
> > + struct conf_mgm_data *cdata;
> > +
> > + cdata = (struct conf_mgm_data *)(evbuf + 1);
> > + if (cdata->ev_qualifier == EV_QUAL_CAP_CHANGE)
> > + /* Will be parsed. Don't change. */
> > + printk(KERN_WARNING "sclp: CPU capability changed.\n");
> > +}
>
> What's that? I do not think printk provides guaranteed delivery.
True. But which generic interface is currently used to notify user space
of state changes? Maybe a uevent for the cpu device..
> > +static struct sclp_register sclp_conf_register =
> > +{
> > + .receive_mask = EvTyp_ConfMgmData_Mask,
>
> NoCamelCasePlease.
>
> > @@ -27,6 +27,7 @@
> > #define EvTyp_CntlProgIdent 0x0B
> > #define EvTyp_SigQuiesce 0x1D
> > #define EvTyp_VT220Msg 0x1A
> > +#define EvTyp_ConfMgmData 0x04
> >
> > #define EvTyp_OpCmd_Mask 0x80000000
> > #define EvTyp_Msg_Mask 0x40000000
> > @@ -36,6 +37,7 @@
> > #define EvTyp_CtlProgIdent_Mask 0x00200000
> > #define EvTyp_SigQuiesce_Mask 0x00000008
> > #define EvTyp_VT220Msg_Mask 0x00000040
> > +#define EvTyp_ConfMgmData_Mask 0x10000000
> >
> > #define GnrlMsgFlgs_DOM 0x8000
> > #define GnrlMsgFlgs_SndAlrm 0x4000
>
> Yep, you have more CamelCases to fix.
Yes, you're definately right. But I wanted to stick with the current
coding style of the sclp device driver and didn't feel like generating
a 1000+ line diff just to fix some coding style issues.
Will fix this when I'm bored.
next prev parent reply other threads:[~2007-03-28 6:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-26 21:24 [patch 0/8] s390 patches for 2.6.22 Heiko Carstens
2007-03-26 21:25 ` [patch 1/8] Processor degredation support Heiko Carstens
2007-03-27 21:35 ` Pavel Machek
2007-03-28 6:54 ` Heiko Carstens [this message]
2007-03-28 8:41 ` Pavel Machek
2007-04-02 18:52 ` Heiko Carstens
2007-03-26 21:25 ` [patch 2/8] Get rid of console setup functions Heiko Carstens
2007-03-26 21:25 ` [patch 3/8] Improved kernel stack overflow checking Heiko Carstens
2007-03-26 21:25 ` [patch 4/8] cio: Clean up online_store Heiko Carstens
2007-03-26 21:25 ` [patch 5/8] cio: Channel-path configure function Heiko Carstens
2007-03-26 21:25 ` [patch 6/8] dasd: Add sysfs attribute status and generate uevents Heiko Carstens
2007-03-26 21:25 ` [patch 7/8] dasd: Add ipldev parameter Heiko Carstens
2007-03-26 21:25 ` [patch 8/8] zfcpdump support Heiko Carstens
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=20070328065443.GA8146@osiris.boeblingen.de.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=schwidefsky@de.ibm.com \
/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
Powered by JetHome