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]
Message-ID: <8bd0f97a0705211501h3684ec80kc74af2cc898806aa@mail.gmail.com>
Date:	Mon, 21 May 2007 18:01:57 -0400
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"Robin Getz" <rgetz@...ckfin.uclinux.org>
Cc:	"Bryan Wu" <bryan.wu@...log.com>, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/32] Blackfin update for 2.6.22-rc2

On 5/21/07, Robin Getz <rgetz@...ckfin.uclinux.org> wrote:
> On Mon 21 May 2007 13:36, Mike Frysinger pondered:
> > On 5/21/07, Robin Getz <rgetz@...ckfin.uclinux.org> wrote:
> > > since there is noMMU, are we better:
> > >  - putting stubs (return ENOSYS - give runtime errors), or
> > >  - just ignore the errors - and give compile errors? (Is there any way to
> > > put something into the syscall table, as not to get the warnings?)
> >
> > there are no compile errors ... having a stub that returns -ENOSYS is
> > the same thing as not having a stub as the fallback code when given an
> > unknown syscall # will return -ENOSYS ...
>
> So, is there a way to tell ./scripts/checksyscalls.sh that here is a list of
> syscalls that we can't do/have chosen not to implement - so we can live with
> the common fallback code, and not get the warnings?

we'd have to define some lists ... like an "obsolete" list where we
could say "do not warn about function XXX if function YYY is supplied"
... for example, we dont provide mmap() because we only use mmap2()
...

then we'd need a list for no-mmu where we could list ones that dont
make sense for us ...

to be sure, there are functions in that list we should be implementing
but no one has noticed/complained so it hasnt been an issue ;)
-mike
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ