On Wed, Jun 06, 2007 at 02:51:02PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
Applied.
Thanks.
Josef "Jeff" Sipek.
--
Don't drink and derive. Alcohol and algebra don't mix.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a mes
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section marker in header file:
WARNING: fs/unionfs/unionfs.o(.init.text+0x56): Section mismatch: reference to
.exit.text:stop_sioq (between 'init_module' and 'init_sioq')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
fs/unionfs/sioq.h |2 +-
On Wed, Jun 06, 2007 at 09:26:26AM -0400, Stephen Smalley wrote:
> On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
> > On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
> > > Hi!
> > >
> > > > Pathname matching, transition table loading, profile loading and
> > > > manipulation.
> >
On Thu, 2007-05-31 at 18:29 +0200, Miklos Szeredi wrote:
> I started working on adding support for unprivileged mounts[1] to
> util-linux.
>
> The big obstacle seems to be the reliance on /etc/mtab, since that
> won't be kept up-to-date after mount(2) or umount(2) calls by
> unprivileged users.
s
On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
> On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
> > Hi!
> >
> > > Pathname matching, transition table loading, profile loading and
> > > manipulation.
> >
> > So we get small interpretter of state machines, and reason we need is
>
On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote:
> On Monday 04 June 2007 15:12, Pavel Machek wrote:
> > How will kernel work with very long paths? I'd suspect some problems,
> > if path is 1MB long and I attempt to print it in /proc
> > somewhere.
>
> Pathnames are only used for info
On Wednesday 06 June 2007, David Woodhouse wrote:
> And if I had something like this (which is admittedly contrived, but
> hardware people _do_ do stupid things to us):
> { uint32_t, uint8_t, uint16_t, uint8_t, uint32_t, uint32_t }
>
> With the 'packed' attribute the compiler would assume arbit
Jörn Engel wrote:
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/fs/logfs/logfs.h 2007-06-03 19:34:07.0 +0200
@@ -0,0 +1,398 @@
+/*
+ * fs/logfs/logfs.h
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007 Joern E
On Wed, 6 June 2007 12:29:13 +0100, Paulo Marques wrote:
> Jörn Engel wrote:
> >--- /dev/null2007-03-13 19:15:28.862769062 +0100
> >+++ linux-2.6.21logfs/fs/logfs/logfs.h 2007-06-03
> >19:34:07.0 +0200
> >@@ -0,0 +1,398 @@
> >+/*
> >+ * fs/logfs/logfs.h
> >+ *
> >+ * As shoul
David Woodhouse <[EMAIL PROTECTED]> writes:
> Won't a simple struct { uint16_t } get padded to a size of 4 bytes on
> ARM? Even if I'm misremembering that, I certainly can't guarantee that
> such a thing will _never_ happen on any newly-invented ABI. If you had
> 'nopadding' instead of 'packed', t
On Tue, Jun 05, 2007 at 03:23:40PM -0400, Jeff Layton wrote:
> I recently sent a similar, smaller patch for this problem. After some
> discussion with Steve and Shaggy, I think I better understand why cifsd
> allows signals through, and I realize that my earlier patch wasn't
> comprehensive enough
On Tue, 2007-06-05 at 20:49 +0200, Segher Boessenkool wrote:
> >>> It would be better if GCC had a 'nopadding' attribute which gave us
> >>> what we need without the _extra_ implications about alignment.
> >>
> >> That's impossible; removing the padding from a struct
> >> _will_ make accesses to it
12 matches
Mail list logo
