Hi Mike,
On Thursday 02 August 2007 21:09, Mike Snitzer wrote:
But NBD's synchronous nature is actually an asset when coupled with
MD raid1 as it provides guarantees that the data has _really_ been
mirrored remotely.
And bio completion doesn't?
Regards,
Daniel
-
To unsubscribe from this
On Friday 03 August 2007 03:26, Evgeniy Polyakov wrote:
On Thu, Aug 02, 2007 at 02:08:24PM -0700, I wrote:
I see bits that worry me, e.g.:
+ req = mempool_alloc(st-w-req_pool, GFP_NOIO);
which seems to be callable in response to a local request, just the
case where NBD
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
> Hi.
>
> I'm pleased to announce first release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
Hi Linus,
On Wednesday 01 August 2007 19:17, Linus Torvalds wrote:
>And the "approximates" thing would be about the fact that we don't
>actually care about "absolute" microseconds as much as something
> that is in the "roughly a microsecond" area. So if we say "it doesn't
> have to be
Hi Linus,
On Wednesday 01 August 2007 19:17, Linus Torvalds wrote:
And the approximates thing would be about the fact that we don't
actually care about absolute microseconds as much as something
that is in the roughly a microsecond area. So if we say it doesn't
have to be microseconds,
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
Hi.
I'm pleased to announce first release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes, which in turn can be exported to another storage as a node to
form tree-like storages.
On Tuesday 10 July 2007 14:03, Chris Mason wrote:
> This patch aims to demonstrate one way to replace buffer heads with a
> few extent trees...
Hi Chris,
Quite terse commentary on algorithms and data structures, but I suppose
that is not a problem because Jon has a whole week to reverse engineer
On Tuesday 10 July 2007 14:03, Chris Mason wrote:
This patch aims to demonstrate one way to replace buffer heads with a
few extent trees...
Hi Chris,
Quite terse commentary on algorithms and data structures, but I suppose
that is not a problem because Jon has a whole week to reverse engineer
On Wednesday 11 July 2007 15:09, Neil Brown wrote:
> > > Has anyone fixed the infrequent crashes with 4K stacks and ext3
> > > -> LVM snapshot -> LVM -> DM mirror -> libata?
> >
> > Ahem: ext3 -> LVM snapshot -> LVM -> DM mirror -> DM crypt -> md ->
> > libata, or worse.
> >
> > No, it's not
On Wednesday 11 July 2007 10:54, Zan Lynx wrote:
> Jesper Juhl wrote:
> > Hi,
> >
> > I'm wondering if it's time to make 4K stacks the default and to start
> > considering removing the 8K stack option alltogether soon?
> >
> > One of the big problem spots was XFS, but that got some stack usage
> >
On Wednesday 11 July 2007 10:54, Zan Lynx wrote:
Jesper Juhl wrote:
Hi,
I'm wondering if it's time to make 4K stacks the default and to start
considering removing the 8K stack option alltogether soon?
One of the big problem spots was XFS, but that got some stack usage
fixes
On Wednesday 11 July 2007 15:09, Neil Brown wrote:
Has anyone fixed the infrequent crashes with 4K stacks and ext3
- LVM snapshot - LVM - DM mirror - libata?
Ahem: ext3 - LVM snapshot - LVM - DM mirror - DM crypt - md -
libata, or worse.
No, it's not fixed. The model is wrong.
Hi Ingo,
I just thought I would mention this, because it is certainly on my
mind. I can't help
wondering if other folks are also concerned about this. The thing is,
why don't you
just send your patches to Con who got this whole ball rolling and did a bunch of
great work, proving beyond any
Hi Ingo,
I just thought I would mention this, because it is certainly on my
mind. I can't help
wondering if other folks are also concerned about this. The thing is,
why don't you
just send your patches to Con who got this whole ball rolling and did a bunch of
great work, proving beyond any
On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
Ah, there's another issue: an interrupt can come in when esp is on the ndis
stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
this one is nasty.
Regards,
Daniel
-
To unsubscribe from this list: send the line
> > Is there a technical reason ("hard to implement" is a practical reason)
> > why all stacks need to be the same size?
>
> Because of
>
> static inline struct thread_info *current_thread_info(void)
> {
> struct thread_info *ti;
> __asm__("andl %%esp,%0; ":"=r" (ti) : ""
Is there a technical reason (hard to implement is a practical reason)
why all stacks need to be the same size?
Because of
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
__asm__(andl %%esp,%0; :=r (ti) : (~(THREAD_SIZE - 1)));
On Wednesday 07 September 2005 15:52, Daniel Phillips wrote:
Ah, there's another issue: an interrupt can come in when esp is on the ndis
stack and above THREAD_SIZE, so do_IRQ will not find thread_info. Sorry,
this one is nasty.
Regards,
Daniel
-
To unsubscribe from this list: send the line
On Wednesday 07 September 2005 00:16, Daniel Phillips wrote:
> ...as long as ->task and ->previous_esp are initialized,
> staying on the bigger stack looks fine (previous_esp is apparently used
> only for backtrace) ... just like do_IRQ.
Ahem, but let me note before somebody else
On Tuesday 06 September 2005 21:59, Mark Lord wrote:
> Daniel Phillips wrote:
> > There are only two stacks involved, the normal kernel stack and your new
> > ndis stack. You save ESP of the kernel stack at the base of the ndis
> > stack. When the Windows code calls your
On Tuesday 06 September 2005 18:28, Roland Dreier wrote:
> Daniel> There are only two stacks involved, the normal kernel
> Daniel> stack and your new ndis stack. You save ESP of the kernel
> Daniel> stack at the base of the ndis stack. When the Windows
> Daniel> code calls your
On Tuesday 06 September 2005 18:21, Andi Kleen wrote:
> On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
> > Andi, their stack will have to have a valid thread_info->task because
> > interrupts will use it. Out of interest, could you please explain what
> &
On Tuesday 06 September 2005 13:23, Giridhar Pemmasani wrote:
> Jan Kiszka wrote:
> > The only way I see is to switch stacks back on ndiswrapper API entry.
> > But managing all those stacks correctly is challenging,
There are only two stacks involved, the normal kernel stack and your new ndis
On Tuesday 06 September 2005 02:55, Dmitry Torokhov wrote:
> On Tuesday 06 September 2005 01:48, Daniel Phillips wrote:
> > On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> > > do you think it is a bit premature to dismiss something even without
> > > ever s
On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> do you think it is a bit premature to dismiss something even without
> ever seeing the code?
You told me you are using a dlm for a single-node application, is there
anything more I need to know?
Regards,
Daniel
-
To unsubscribe from
On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
do you think it is a bit premature to dismiss something even without
ever seeing the code?
You told me you are using a dlm for a single-node application, is there
anything more I need to know?
Regards,
Daniel
-
To unsubscribe from
On Tuesday 06 September 2005 02:55, Dmitry Torokhov wrote:
On Tuesday 06 September 2005 01:48, Daniel Phillips wrote:
On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
do you think it is a bit premature to dismiss something even without
ever seeing the code?
You told me you
On Tuesday 06 September 2005 13:23, Giridhar Pemmasani wrote:
Jan Kiszka wrote:
The only way I see is to switch stacks back on ndiswrapper API entry.
But managing all those stacks correctly is challenging,
There are only two stacks involved, the normal kernel stack and your new ndis
stack.
On Tuesday 06 September 2005 18:21, Andi Kleen wrote:
On Wednesday 07 September 2005 00:19, Daniel Phillips wrote:
Andi, their stack will have to have a valid thread_info-task because
interrupts will use it. Out of interest, could you please explain what
for?
No, with 4k interrupts run
On Tuesday 06 September 2005 18:28, Roland Dreier wrote:
Daniel There are only two stacks involved, the normal kernel
Daniel stack and your new ndis stack. You save ESP of the kernel
Daniel stack at the base of the ndis stack. When the Windows
Daniel code calls your api, you
On Tuesday 06 September 2005 21:59, Mark Lord wrote:
Daniel Phillips wrote:
There are only two stacks involved, the normal kernel stack and your new
ndis stack. You save ESP of the kernel stack at the base of the ndis
stack. When the Windows code calls your api, you get the ndis ESP, load
On Wednesday 07 September 2005 00:16, Daniel Phillips wrote:
...as long as -task and -previous_esp are initialized,
staying on the bigger stack looks fine (previous_esp is apparently used
only for backtrace) ... just like do_IRQ.
Ahem, but let me note before somebody else does: it isn't
On Monday 05 September 2005 19:37, Joel Becker wrote:
> OCFS2, the new filesystem, is fully general purpose. It
> supports all the usual stuff, is quite fast...
So I have heard, but isn't it time to quantify that? How do you think you
would stack up here:
On Tuesday 06 September 2005 00:07, Dmitry Torokhov wrote:
> On Monday 05 September 2005 23:02, Daniel Phillips wrote:
> > By the way, you said "alpha server" not "alpha servers", was that just a
> > slip? Because if you don't have a cluster then why are you us
On Monday 05 September 2005 22:03, Dmitry Torokhov wrote:
> On Monday 05 September 2005 19:57, Daniel Phillips wrote:
> > On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
> > > On Monday 05 September 2005 10:49, Daniel Phillips wrote:
> > > > On Monday
On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
> On Monday 05 September 2005 10:49, Daniel Phillips wrote:
> > On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
> > > On 2005-09-03T01:57:31, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > >
On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
> On 2005-09-03T01:57:31, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > The only current users of dlms are cluster filesystems. There are zero
> > users of the userspace dlm api.
>
> That is incorrect...
Ap
On Monday 05 September 2005 05:19, Andrew Morton wrote:
> David Teigland <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 05, 2005 at 01:54:08AM -0700, Andrew Morton wrote:
> > > David Teigland <[EMAIL PROTECTED]> wrote:
> > > > We export our full dlm API through read/write/poll on a misc device.
> > >
On Monday 05 September 2005 05:19, Andrew Morton wrote:
David Teigland [EMAIL PROTECTED] wrote:
On Mon, Sep 05, 2005 at 01:54:08AM -0700, Andrew Morton wrote:
David Teigland [EMAIL PROTECTED] wrote:
We export our full dlm API through read/write/poll on a misc device.
inotify did
On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
On 2005-09-03T01:57:31, Daniel Phillips [EMAIL PROTECTED] wrote:
The only current users of dlms are cluster filesystems. There are zero
users of the userspace dlm api.
That is incorrect...
Application users Lars, sorry if I did
On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
On Monday 05 September 2005 10:49, Daniel Phillips wrote:
On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
On 2005-09-03T01:57:31, Daniel Phillips [EMAIL PROTECTED] wrote:
The only current users of dlms are cluster
On Monday 05 September 2005 22:03, Dmitry Torokhov wrote:
On Monday 05 September 2005 19:57, Daniel Phillips wrote:
On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
On Monday 05 September 2005 10:49, Daniel Phillips wrote:
On Monday 05 September 2005 10:14, Lars Marowsky-Bree
On Tuesday 06 September 2005 00:07, Dmitry Torokhov wrote:
On Monday 05 September 2005 23:02, Daniel Phillips wrote:
By the way, you said alpha server not alpha servers, was that just a
slip? Because if you don't have a cluster then why are you using a dlm?
No, it is not a slip
On Monday 05 September 2005 19:37, Joel Becker wrote:
OCFS2, the new filesystem, is fully general purpose. It
supports all the usual stuff, is quite fast...
So I have heard, but isn't it time to quantify that? How do you think you
would stack up here:
On Sunday 04 September 2005 03:28, Andrew Morton wrote:
> If there is already a richer interface into all this code (such as a
> syscall one) and it's feasible to migrate the open() tricksies to that API
> in the future if it all comes unstuck then OK. That's why I asked (thus
> far
On Sunday 04 September 2005 00:46, Andrew Morton wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > The model you came up with for dlmfs is beyond cute, it's downright
> > clever.
>
> Actually I think it's rather sick. Taking O_NONBLOCK and making it a
> lock-m
On Sunday 04 September 2005 00:46, Andrew Morton wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
The model you came up with for dlmfs is beyond cute, it's downright
clever.
Actually I think it's rather sick. Taking O_NONBLOCK and making it a
lock-manager trylock because they're kinda
On Sunday 04 September 2005 03:28, Andrew Morton wrote:
If there is already a richer interface into all this code (such as a
syscall one) and it's feasible to migrate the open() tricksies to that API
in the future if it all comes unstuck then OK. That's why I asked (thus
far unsuccessfully):
On Sunday 04 September 2005 01:00, Joel Becker wrote:
> On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote:
> > Clearly, I ought to have asked why dlmfs can't be done by configfs. It
> > is the same paradigm: drive the kernel logic from user-initiated vfs
> >
On Sunday 04 September 2005 00:30, Joel Becker wrote:
> You asked why dlmfs can't go into sysfs, and I responded.
And you got me! In the heat of the moment I overlooked the fact that you and
Greg haven't agreed to the merge yet ;-)
Clearly, I ought to have asked why dlmfs can't be done by
On Saturday 03 September 2005 23:06, Joel Becker wrote:
> dlmfs is *tiny*. The VFS interface is less than his claimed 500
> lines of savings.
It is 640 lines.
> The few VFS callbacks do nothing but call DLM
> functions. You'd have to replace this VFS glue with sysfs glue, and
> probably save
On Saturday 03 September 2005 02:46, Wim Coekaerts wrote:
> On Sat, Sep 03, 2005 at 02:42:36AM -0400, Daniel Phillips wrote:
> > On Friday 02 September 2005 20:16, Mark Fasheh wrote:
> > > As far as userspace dlm apis go, dlmfs already abstracts away a large
> > >
On Saturday 03 September 2005 06:35, David Teigland wrote:
> Just a new version, not a big difference. The ondisk format changed a
> little making it incompatible with the previous versions. We'd been
> holding out on the format change for a long time and thought now would be
> a sensible time
On Friday 02 September 2005 20:16, Mark Fasheh wrote:
> As far as userspace dlm apis go, dlmfs already abstracts away a large part
> of the dlm interaction...
Dumb question, why can't you use sysfs for this instead of rolling your own?
Side note: you seem to have deleted all the 2.6.12-rc4
On Friday 02 September 2005 20:16, Mark Fasheh wrote:
As far as userspace dlm apis go, dlmfs already abstracts away a large part
of the dlm interaction...
Dumb question, why can't you use sysfs for this instead of rolling your own?
Side note: you seem to have deleted all the 2.6.12-rc4
On Saturday 03 September 2005 06:35, David Teigland wrote:
Just a new version, not a big difference. The ondisk format changed a
little making it incompatible with the previous versions. We'd been
holding out on the format change for a long time and thought now would be
a sensible time to
On Saturday 03 September 2005 02:46, Wim Coekaerts wrote:
On Sat, Sep 03, 2005 at 02:42:36AM -0400, Daniel Phillips wrote:
On Friday 02 September 2005 20:16, Mark Fasheh wrote:
As far as userspace dlm apis go, dlmfs already abstracts away a large
part of the dlm interaction...
Dumb
On Saturday 03 September 2005 23:06, Joel Becker wrote:
dlmfs is *tiny*. The VFS interface is less than his claimed 500
lines of savings.
It is 640 lines.
The few VFS callbacks do nothing but call DLM
functions. You'd have to replace this VFS glue with sysfs glue, and
probably save very
On Sunday 04 September 2005 00:30, Joel Becker wrote:
You asked why dlmfs can't go into sysfs, and I responded.
And you got me! In the heat of the moment I overlooked the fact that you and
Greg haven't agreed to the merge yet ;-)
Clearly, I ought to have asked why dlmfs can't be done by
On Sunday 04 September 2005 01:00, Joel Becker wrote:
On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote:
Clearly, I ought to have asked why dlmfs can't be done by configfs. It
is the same paradigm: drive the kernel logic from user-initiated vfs
methods. You already have
On Friday 02 September 2005 17:17, Andi Kleen wrote:
> The only thing that should be probably resolved is a common API
> for at least the clustered lock manager. Having multiple
> incompatible user space APIs for that would be sad.
The only current users of dlms are cluster filesystems. There
On Friday 02 September 2005 15:41, Miklos Szeredi wrote:
> Already dead ;)
>
> 2.6.13-mm1: remove-ia_attr_flags.patch
>
> Miklos
Wow, the pace of Linux development really is picking up. Now patches are
applied before I even send them!
Regards,
Daniel
-
To unsubscribe from this list: send the
Struct iattr is not involved any more in such things as NOATIME inode flags.
There are no in-tree users of ia_attr_flags.
Signed-off-by Daniel Phillips <[EMAIL PROTECTED]>
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/hostfs/hostfs.h
2.6.13-rc5-mm1/fs/hostfs/hostfs.h
--- 2.6.13-rc5-mm1.cl
Struct iattr is not involved any more in such things as NOATIME inode flags.
There are no in-tree users of ia_attr_flags.
Signed-off-by Daniel Phillips [EMAIL PROTECTED]
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/hostfs/hostfs.h
2.6.13-rc5-mm1/fs/hostfs/hostfs.h
--- 2.6.13-rc5-mm1.clean/fs
On Friday 02 September 2005 15:41, Miklos Szeredi wrote:
Already dead ;)
2.6.13-mm1: remove-ia_attr_flags.patch
Miklos
Wow, the pace of Linux development really is picking up. Now patches are
applied before I even send them!
Regards,
Daniel
-
To unsubscribe from this list: send the line
On Friday 02 September 2005 17:17, Andi Kleen wrote:
The only thing that should be probably resolved is a common API
for at least the clustered lock manager. Having multiple
incompatible user space APIs for that would be sad.
The only current users of dlms are cluster filesystems. There are
On Thursday 01 September 2005 06:46, David Teigland wrote:
> I'd like to get a list of specific things remaining for merging.
Where are the benchmarks and stability analysis? How many hours does it
survive cerberos running on all nodes simultaneously? Where are the
testimonials from users?
On Thursday 01 September 2005 10:49, Alan Cox wrote:
> On Iau, 2005-09-01 at 03:59 -0700, Andrew Morton wrote:
> > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > possibly gain (or vice versa)
> >
> > - Relative merits of the two offerings
>
> You missed the important
On Thursday 01 September 2005 10:49, Alan Cox wrote:
On Iau, 2005-09-01 at 03:59 -0700, Andrew Morton wrote:
- Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
possibly gain (or vice versa)
- Relative merits of the two offerings
You missed the important one -
On Thursday 01 September 2005 06:46, David Teigland wrote:
I'd like to get a list of specific things remaining for merging.
Where are the benchmarks and stability analysis? How many hours does it
survive cerberos running on all nodes simultaneously? Where are the
testimonials from users?
On Wednesday 31 August 2005 09:34, [EMAIL PROTECTED] wrote:
> On Tue, Aug 30, 2005 at 04:28:46PM -0700, Andrew Morton wrote:
> > Sure, but all that copying-and-pasting really sucks. I'm sure there's
> > some way of providing the slightly different semantics from the same
> > codebase?
>
> Careful
On Wednesday 31 August 2005 09:28, Andrew Morton wrote:
> Joel Becker <[EMAIL PROTECTED]> wrote:
> > On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> > > But it would be stupid to forbid users from creating directories in
> > > sysfs or to fo
On Wednesday 31 August 2005 09:25, Daniel Phillips wrote:
> On Wednesday 31 August 2005 09:13, Joel Becker wrote:
> > On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> > > But it would be stupid to forbid users from creating directories in
> > > sysfs
(without kmail bugs this time)
A kernel code example that uses the modified configfs to define a simple
configuration interface. Note the use of kobjects and ksets instead of
config_items and config_groups.
Also notice how much code is required to get a simple value from
userspace to kernel
On Wednesday 31 August 2005 09:13, Joel Becker wrote:
> On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
> > But it would be stupid to forbid users from creating directories in sysfs
> > or to forbid kernel modules from directly tweaking a configfs namespace.
(avoiding the kmail formatting problems this time.)
Sysfs rearranged as a single file for analysis purposes.
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile
2.6.13-rc5-mm1/fs/sysfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile 2005-06-17 15:48:29.0
-0400
+++
On Tuesday 30 August 2005 19:06, Stephen Hemminger wrote:
> On Wed, 31 Aug 2005 08:59:55 +1000
>
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > Configfs rewritten as a single file and updated to use kobjects instead
> > of its own clone of kobjects (config_items).
>
On Wednesday 31 August 2005 08:59, Daniel Phillips wrote:
> -obj-$(CONFIG_CONFIGFS_FS) += configfs.o
> +obj-$(CONFIG_CONFIGFS_FS) += configfs.o ddbond.config.o
This should just be:
+obj-$(CONFIG_CONFIGFS_FS) += configfs.o
However, the wrong version does provide a convenient way of com
A kernel code example that uses the modified configfs to define a simple
configuration interface. Note the use of kobjects and ksets instead of
config_items and config_groups.
Also notice how much code is required to get a simple value from
userspace to kernel space. This is a big problem that
Configfs rewritten as a single file and updated to use kobjects instead of its
own clone of kobjects (config_items).
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/configfs/Makefile
2.6.13-rc5-mm1/fs/configfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/configfs/Makefile 2005-08-09 18:23:30.0
Sysfs rearranged as a single file for analysis purposes.
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile
2.6.13-rc5-mm1/fs/sysfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile 2005-06-17 15:48:29.0 -0400
+++ 2.6.13-rc5-mm1/fs/sysfs/Makefile 2005-08-29 17:13:59.0
Hi Andrew,
Configfs blithely ingests kobject.h and kobject.c into itself, just changing
the names. Furthermore, more than half of configfs is copied verbatim from
sysfs, the only difference being the name changes. After undoing the name
changes and adding a few new fields to kobject
Sysfs rearranged as a single file for analysis purposes.
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile
2.6.13-rc5-mm1/fs/sysfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile 2005-06-17 15:48:29.0 -0400
+++ 2.6.13-rc5-mm1/fs/sysfs/Makefile 2005-08-29 17:13:59.0
Configfs rewritten as a single file and updated to use kobjects instead of its
own clone of kobjects (config_items).
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/configfs/Makefile
2.6.13-rc5-mm1/fs/configfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/configfs/Makefile 2005-08-09 18:23:30.0
A kernel code example that uses the modified configfs to define a simple
configuration interface. Note the use of kobjects and ksets instead of
config_items and config_groups.
Also notice how much code is required to get a simple value from
userspace to kernel space. This is a big problem that
On Wednesday 31 August 2005 08:59, Daniel Phillips wrote:
-obj-$(CONFIG_CONFIGFS_FS) += configfs.o
+obj-$(CONFIG_CONFIGFS_FS) += configfs.o ddbond.config.o
This should just be:
+obj-$(CONFIG_CONFIGFS_FS) += configfs.o
However, the wrong version does provide a convenient way of compiling
On Tuesday 30 August 2005 19:06, Stephen Hemminger wrote:
On Wed, 31 Aug 2005 08:59:55 +1000
Daniel Phillips [EMAIL PROTECTED] wrote:
Configfs rewritten as a single file and updated to use kobjects instead
of its own clone of kobjects (config_items).
Some style issues:
Mixed case
(avoiding the kmail formatting problems this time.)
Sysfs rearranged as a single file for analysis purposes.
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile
2.6.13-rc5-mm1/fs/sysfs/Makefile
--- 2.6.13-rc5-mm1.clean/fs/sysfs/Makefile 2005-06-17 15:48:29.0
-0400
+++
On Wednesday 31 August 2005 09:13, Joel Becker wrote:
On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
But it would be stupid to forbid users from creating directories in sysfs
or to forbid kernel modules from directly tweaking a configfs namespace.
Why should the kernel
(without kmail bugs this time)
A kernel code example that uses the modified configfs to define a simple
configuration interface. Note the use of kobjects and ksets instead of
config_items and config_groups.
Also notice how much code is required to get a simple value from
userspace to kernel
On Wednesday 31 August 2005 09:25, Daniel Phillips wrote:
On Wednesday 31 August 2005 09:13, Joel Becker wrote:
On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
But it would be stupid to forbid users from creating directories in
sysfs or to forbid kernel modules from
On Wednesday 31 August 2005 09:28, Andrew Morton wrote:
Joel Becker [EMAIL PROTECTED] wrote:
On Wed, Aug 31, 2005 at 08:54:39AM +1000, Daniel Phillips wrote:
But it would be stupid to forbid users from creating directories in
sysfs or to forbid kernel modules from directly tweaking
On Wednesday 31 August 2005 09:34, [EMAIL PROTECTED] wrote:
On Tue, Aug 30, 2005 at 04:28:46PM -0700, Andrew Morton wrote:
Sure, but all that copying-and-pasting really sucks. I'm sure there's
some way of providing the slightly different semantics from the same
codebase?
Careful - you've
On Monday 22 August 2005 00:49, Eric W. Biederman wrote:
> I am confused. I am beginning to see shades of the devfs problems coming
> up again. sysfs is built to be world readable by everyone who has it
> mounted in their namespace. Writable files in sysfs I have never
> understood.
Sysfs is
On Monday 22 August 2005 00:49, Eric W. Biederman wrote:
I am confused. I am beginning to see shades of the devfs problems coming
up again. sysfs is built to be world readable by everyone who has it
mounted in their namespace. Writable files in sysfs I have never
understood.
Sysfs is not
On Saturday 20 August 2005 13:01, Greg KH wrote:
> On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
> > Permissions set on ConfigFS attributes (aka files) do not stick.
>
> The recent changes to sysfs should be ported to configfs to do this.
No, it should go the ot
On Saturday 20 August 2005 20:45, David Howells wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > Biased. Fs is a mixed case acronym, nuff said.
>
> But I'm still right:-)
Of course you are! We're only impugning your taste, not your logic ;-)
OK, the questions re yo
On Saturday 20 August 2005 16:31, Joel Becker wrote:
> On Fri, Aug 19, 2005 at 08:01:17PM -0700, Greg KH wrote:
> > The recent changes to sysfs should be ported to configfs to do this.
>
> Yeah, I've been meaning to do something, and resusing code is
> always a good plan.
Ending up with the
On Saturday 20 August 2005 11:22, Jon Smirl wrote:
> A patch for making sysfs attributes persistent has recently made it
> into Linus' tree.
>
>
http://article.gmane.org/gmane.linux.hotplug.devel/7927/match=sysfs+permissions
Interesting, it handles more than just the file mode. But does anybody
On Saturday 20 August 2005 11:22, Jon Smirl wrote:
A patch for making sysfs attributes persistent has recently made it
into Linus' tree.
http://article.gmane.org/gmane.linux.hotplug.devel/7927/match=sysfs+permissions
Interesting, it handles more than just the file mode. But does anybody
501 - 600 of 1437 matches
Mail list logo
