linux-kernel - Re: [RFC PATCH v1 14/31] ARC: syscall support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Nov 2012 12:13:23 +0200
From:	Gilad Ben-Yossef <gilad@...yossef.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: [RFC PATCH v1 14/31] ARC: syscall support

On Wed, Nov 7, 2012 at 4:21 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Wednesday 07 November 2012, Vineet Gupta wrote:
>> + * Being uClibc based we need some of the deprecated syscalls:
>> + * -Not emulated by uClibc at all
>> + *     unlink, mkdir,... (needed by Busybox, LTP etc)
>> + *     times (needed by LTP pan test harness)
>> + * -Not emulated efficiently
>> + *     select: emulated using pselect (but extra code to chk usec > 1sec)
>> + *
> ...
> I'm pretty sure that this has been solved before, best get in contact with
> the maintainers of the openrisc/c6x/hexagon platforms, that probably all
> use uClibc without needing these.
>
> You have to remove the legacy calls here.

So, I completely agree about not adding more deprecated system call or
ABIs (thinking about the ptrace regset issues in another patch in the
same patchset), but on the other hand I have to wonder if having a
port in the tree that doesn't have a working C library or a debugger
makes sense.

I mean, it is not quite the same thing as saying: "well, users of the
old versions of the user tools will need to maintain out of tree
patches". That makes sense - it puts the burden of maintenance on
people clinging to new versions when newer one exists, but this is not
what is happening with Arc. Right now, there are no working version of
the tools for Arc, so everyone will need to use the out of tree
patches.

I wonder what is worse - having an in tree port that no one (can) use
or adding some deprecated crap (sorry...), clearly marked for deletion
the minute a version of the relevant user tools exists that can be
used with the new mechanisms?

Just my 2c as an Arc kernel port user,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@...yossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/