Hi. On Tuesday 07 February 2006 09:51, Rafael J. Wysocki wrote: > Hi, > > On Monday 06 February 2006 21:25, Nigel Cunningham wrote: > > On Tuesday 07 February 2006 04:48, Lee Revell wrote: > > > On Mon, 2006-02-06 at 15:43 +1000, Nigel Cunningham wrote: > > > > Hi. > > > > > > > > On Monday 06 February 2006 14:34, Lee Revell wrote: > > > > > On Mon, 2006-02-06 at 14:02 +1000, Nigel Cunningham wrote: > > > > > > (they now have to download extra > > > > > > libraries to use the splashscreen, which were not required > > > > > > with the bootsplash patch, and need to check whether an update > > > > > > to the userui code > > > > > > is required when updating the kernel) > > > > > > > > > > You could have avoided this problem by keeping the > > > > > userspace<->kernel interface stable. > > > > > > > > True, but sometimes you need to make changes that do modify the > > > > interface. If the interface involves more functionality, this will > > > > happen more frequently. > > > > > > Well, all I can say is, it should have been obvious that putting a > > > themeable UI in the kernel would not fly. > > > > Agreed, but I think we have some confusion here. > > > > I was talking about interactions between kernel space and userspace > > after we started using the userspace interface. In particular, I was > > thinking of the fact that the netlink message number kept changing due > > to changes in the vanilla kernel. In the end, we just made it a > > command line option to the userui. > > > > My point for this conversation was different, though. If uswsusp ever > > does fly, there are going to be flag days where users are going to > > have to download new userspace code, perhaps new versions of libraries > > or new libraries, run the compilation and reconfigure their > > initrds/ram-fses, all just because they upgraded their kernel and want > > to continue to suspend to disk. That is extra complexity introduced by > > using a userspace 'brain' instead of having it in kernelspace. > > This point is valid, but I don't think the users will _have_ _to_ switch > to the userland suspend. AFAICT we are going to keep the kernel-based > code as long as necessary. > > We are just going to implement features in the user space that need not > be implemented in the kernel. Of course they can be implemented in the > kernel, and you have shown that clearly, but since they need not be > there, we should at least try to implement them in the user space and > see how this works. > > Frankly, I have no strong opinion on whether they _should_ be > implemented in the user space or in the kernel, but I think we won't > know that until we actually _try_. > > That said, I like the idea and I'm going to work on it. I'll also > appreciate any help very much. Wow. I wish Pavel wrote replies like that. We'd get on a whole lot better. Pavel, am I doing something wrong that I'm not clicking to, which is stirring you up? I really don't want to. I want to work with you guys instead of against you, but it seems to me like every attempt at interaction with you degenerates into something far less than ideal. Regards, Nigel -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode
Attachment:
pgppwowD8bgAp.pgp
Description: PGP signature
- Follow-Ups:
- References:
- [ 00/10] [Suspend2] Modules support.
- From: Nigel Cunningham <[email protected]>
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- From: Nigel Cunningham <[email protected]>
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- From: "Rafael J. Wysocki" <[email protected]>
- [ 00/10] [Suspend2] Modules support.
- Prev by Date: Re: Linux drivers management
- Next by Date: Re: [RFC][PATCH] unify pfn_to_page [25/25] sparc64 pfn_to_page/page_to_pfn
- Previous by thread: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- Next by thread: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- Index(es):