linux-kernel - Re: [RFC, PATCH] watchdog on gpio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8bd0f97a0801140145s5e13083ej926aa9d5f87e3a99@mail.gmail.com>
Date:	Mon, 14 Jan 2008 04:45:25 -0500
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Marc Pignat" <marc.pignat@...s.ch>, wim@...ana.be,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC, PATCH] watchdog on gpio

On Jan 14, 2008 4:29 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > > Saves memory - you can't make inlined strings __initdata without breaking
> > > some compilers. So it is correct.
> >
> > you could make the same argument about all strings used in all __init
> > functions.  making a special case for this one string is just
> > confusing.  this is also used from the *platfrom driver probe*
> > function, not the *module init* function, which means it should be
> > __devinitdata (see below) ... which quickly adds to the
> > confusion/craziness.
>
> Not neccessarily see below. For strings there is a tricky tradeoff
> between space on embedded boxes and simplicity. On a 2GB desktop PC the
> decision is fairly trivial, on a PDA it gets a bit more important.

i'm aware of this (i bang on embedded no-mmu systems).  if his banner
string was crazy long, i'd more understand, but it isnt any longer
than any one of his error strings in the probe function.  in fact, all
of the error strings combined are more than 3x the size of his banner.

wonder if we could design a printk designed for __init functions to
address this in a clean fashion.
#define init_printk(fmt, __VA_ARGS__) \
  do { \
    static const __init char __fmt[] = fmt; \
    printk(__fmt , ## __VA_ARGS__); \
  } while (0)

(yes, i know this isnt perfect as you'd need to pass back the return
value of printk(), but it's an idea)

> > > > > +static int __init gpio_wdt_probe(struct platform_device *pdev)
> > > >
> > > > shouldnt this be __devinit ?
> > >
> > > IFF the device can be found/removed dynamically.
> >
> > wont __init get freed once the module has finished loading ?
>
> If your platform creates the device statically (as a lot of embedded
> platforms do) then the __init is fine. The platform register in
> init_module will call back the driver probe method and attach the device
> before the init_module exits.

there is no hard requirement anywhere that says platform resources
must be in the board resources file.  marking the functions as __init
instead of __devinit will basically cause a kernel crash if someone
tries to use dynamic platform resources.  there is no option that i'm
aware of that prevents dynamic platform resources which means there is
no way for the driver to say "i wont work with standard dynamic
platform resources".
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/