From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [RFC PATCH 0/5] Resend - Use procfs to change a syscall behavior Date: Tue, 8 Jul 2008 12:51:43 +0200 Message-ID: <20080708105143.GA15311@elf.ucw.cz> References: <20080703144013.737951000@bull.net> <20080704102702.GB4531@elf.ucw.cz> <486E1276.2080605@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <486E1276.2080605-6ktuUTfB/bM@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Nadia Derbey Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: containers.vger.kernel.org Hi! >>> An alternative to this solution consists in defining a new field in the >>> task structure (let's call it next_syscall_data) that, if set, would change >>> the behavior of next syscall to be called. The sys_fork_with_id() previously >>> cited can be replaced by >>> 1) set next_syscall_data to a target upid nr >>> 2) call fork(). >> >> >> ...bloat task struct and >> >> >>> A new file is created in procfs: /proc/self/task//next_syscall_data. >>> This makes it possible to avoid races between several threads belonging to >>> the same process. >> >> >> ...introducing this kind of uglyness. >> >> Actually, there were proposals for sys_indirect(), which is slightly >> less ugly, but IIRC we ended up with adding syscalls, too. > I had a look at the lwn.net article that describes the sys_indirect() > interface. > It does exactly what we need here, so I do like it, but it has the same > drawbacks as the one you're complaining about: > . a new field is needed in the task structure > . looks like many people found it ugly... > Now, coming back to what I'm proposing: what we need is actually to change > the behavior of *existing* syscalls, since we are in a very particular > context (restarting an application). Changing existing syscalls is _bad_: for backwards compatibility reasons. strace will be very confusing to read, etc... > Defining brand new syscalls is very touchy: needs to be careful about the > interface + I can't imagine the number of syscalls that would be > needed. Of course new syscalls is touchy... modifying _existing_ should be even more touchy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html