Stefan Reinauer | 1 Jul 01:01
Picon

Re: [PATCH] v3 - spinlock cleanup

* Uwe Hermann <uwe <at> hermann-uwe.de> [070701 00:57]:
> On Sun, Jul 01, 2007 at 12:46:04AM +0200, Stefan Reinauer wrote:
> > -/* Most GCC versions have a nasty bug with empty initializers */
> > -#if (__GNUC__ > 2)
> > -typedef struct { } spinlock_t;
> > -#define SPIN_LOCK_UNLOCKED (spinlock_t) { }
> > -#else
> > -typedef struct { int gcc_is_buggy; } spinlock_t;
> > -#define SPIN_LOCK_UNLOCKED (spinlock_t) { 0 }
> > -#endif
> > -
> 
> ACK. Sending a similar patch was already on my TODO list. We don't care
> about gcc <= 3, I guess.

Check the code, it will work on pre v3 like a charme. I don't know what
those Linux guys must have been smoking, but I better don't try it.

> >  #define spin_unlock(lock)      do {} while(0)
> > +#define spin_define(lock)       /* empty */
> 
> Why not this?
> #define spin_define(lock) do {} while(0)

Haha. I had this first. But a do .. while construct outside a function
scope is nothing gcc (or any other compiler) would handle :-)

> > +#define spin_define(spin) static struct spinlock spin = SPIN_LOCK_UNLOCKED
> 
> Uh, that looks like an inline function might be better here.
(Continue reading)

Peter Stuge | 1 Jul 01:20
Picon

Re: [RFC] v3: dts fixes and questions

On Sat, Jun 30, 2007 at 11:43:20PM +0200, Stefan Reinauer wrote:
> So instead of adding enabled; to all device nodes, we should add
> disabled to those that we do not want enabled. What do you think?

We should definately optimize for the common case whatever it is.

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Peter Stuge | 1 Jul 01:23
Picon

Re: r418 - in LinuxBIOSv3: arch/x86 device include include/arch/x86 include/arch/x86/arch include/device lib util/dtc

On Sat, Jun 30, 2007 at 09:38:32PM +0200, Stefan Reinauer wrote:
> > > +#define barrier() __asm__ __volatile__("": : :"memory")
> > 
> > #define barrier() (__asm__ __volatile__("": : :"memory"))
> 
> this will break code using it. try barrier(); 

#define barier() do { __asm__ .. } while(0)

is common, does it work here?

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Peter Stuge | 1 Jul 01:27
Picon

Re: r418 - in LinuxBIOSv3: arch/x86 device include include/arch/x86 include/arch/x86/arch include/device lib util/dtc

On Sat, Jun 30, 2007 at 02:56:22PM -0700, ron minnich wrote:
> we need to learn how to use stuff like mb(). Oh joy :-)

Isn't all that bad..

Call wmb() to "commit" writes. Call rmb() to "commit" reads. Call
mb() to "commit" both.

Good thing they have short names.

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

ron minnich | 1 Jul 01:27
Picon

Re: [RFC] v3: dts fixes and questions

On 6/30/07, Peter Stuge <peter <at> stuge.se> wrote:
> On Sat, Jun 30, 2007 at 11:43:20PM +0200, Stefan Reinauer wrote:
> > So instead of adding enabled; to all device nodes, we should add
> > disabled to those that we do not want enabled. What do you think?
>
> We should definately optimize for the common case whatever it is.

What I can do is look for a disable property in each node. If it is
NOT found, emit
.enabled = 1;
If it is found,
.enabled = 0;

sound ok?

ron

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Peter Stuge | 1 Jul 01:34
Picon

Re: [RFC] v3: dts fixes and questions

On Sat, Jun 30, 2007 at 04:27:27PM -0700, ron minnich wrote:
> What I can do is look for a disable property in each node. If it is
> NOT found, emit
> .enabled = 1;
> If it is found,
> .enabled = 0;
> 
> sound ok?

Yes sir! As long as enabled is more common than disabled.

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Uwe Hermann | 1 Jul 02:07
Picon
Favicon
Gravatar

Re: [RFC] v3: dts fixes and questions

On Sat, Jun 30, 2007 at 04:27:27PM -0700, ron minnich wrote:
> On 6/30/07, Peter Stuge <peter <at> stuge.se> wrote:
> > On Sat, Jun 30, 2007 at 11:43:20PM +0200, Stefan Reinauer wrote:
> > > So instead of adding enabled; to all device nodes, we should add
> > > disabled to those that we do not want enabled. What do you think?
> >
> > We should definately optimize for the common case whatever it is.
> 
> What I can do is look for a disable property in each node. If it is
> NOT found, emit
> .enabled = 1;
> If it is found,
> .enabled = 0;
> 
> sound ok?

Why not, instead of 'enabled;', use
  enabled="0"
or 
  enabled="1"
then? That has the benefit that you don't have to know what the default
is (enabled or disabled), you know everything you need just by looking
at the dts itself.

Uwe.
--

-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
(Continue reading)

Uwe Hermann | 1 Jul 02:14
Picon
Favicon
Gravatar

Re: [PATCH] v3 - spinlock cleanup

On Sun, Jul 01, 2007 at 01:01:54AM +0200, Stefan Reinauer wrote:
> > >  #define spin_unlock(lock)      do {} while(0)
> > > +#define spin_define(lock)       /* empty */
> > 
> > Why not this?
> > #define spin_define(lock) do {} while(0)
>  
> Haha. I had this first. But a do .. while construct outside a function
> scope is nothing gcc (or any other compiler) would handle :-)

Yep.

 
> > > +#define spin_define(spin) static struct spinlock spin = SPIN_LOCK_UNLOCKED
> > 
> > Uh, that looks like an inline function might be better here.
> 
> Not sure I get what you mean.. This one defines a (file) global
> variable.

OK, I totally misread what the code is supposed to do.

I'm not sure the spin_define() is such a good idea then. It has a nice
name and all, but it might be obfuscating things more than necessary.
Maybe a simple variable declaration (i.e., drop the #define) would be better?

Uwe.
--

-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
(Continue reading)

Picon
Gravatar

Re: ELF loader in v3

On 01.07.2007 00:51, Peter Stuge wrote:
> On Fri, Jun 29, 2007 at 10:03:26PM +0200, Patrick Georgi wrote:
>> My proposal would be to decompress the ELF image to some location,
>> lookk if that location overlaps with the places the data is copied
>> to, and if so, determine a large-enough chunk of memory and
>> decompress it to there again
> 
> Sorry, NAK. I don't like unneccessary work.
> 
> If need be, teach elfboot to peek into compressed streams so that it
> can tell the decompressor a safe place to decomress to.

Sorry, our implementation of lzma decompression does not decompress
to a stream, only in bulk. Choosing streaming decompression is
possible, but the memory requirements made me decide against it.
Decompression speed is also significantly slower for streaming lzma
decompression.

Regards,
Carl-Daniel

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

ron minnich | 1 Jul 05:46
Picon

Re: [RFC] v3: dts fixes and questions

On 6/30/07, Uwe Hermann <uwe <at> hermann-uwe.de> wrote:
> On Sat, Jun 30, 2007 at 04:27:27PM -0700, ron minnich wrote:
> > On 6/30/07, Peter Stuge <peter <at> stuge.se> wrote:
> > > On Sat, Jun 30, 2007 at 11:43:20PM +0200, Stefan Reinauer wrote:
> > > > So instead of adding enabled; to all device nodes, we should add
> > > > disabled to those that we do not want enabled. What do you think?
> > >
> > > We should definately optimize for the common case whatever it is.
> >
> > What I can do is look for a disable property in each node. If it is
> > NOT found, emit
> > .enabled = 1;
> > If it is found,
> > .enabled = 0;
> >
> > sound ok?
>
> Why not, instead of 'enabled;', use
>   enabled="0"
> or
>   enabled="1"
> then? That has the benefit that you don't have to know what the default
> is (enabled or disabled), you know everything you need just by looking
> at the dts itself.
>
>
> Uwe.
> --
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
(Continue reading)


Gmane