On May 13, 2025 2:53:23 AM PDT, Arnd Bergmann wrote:
>On Tue, May 13, 2025, at 11:17, Andrey Albershteyn wrote:
>
>>
>> long syscall(SYS_file_getattr, int dirfd, const char *pathname,
>> struct fsxattr *fsx, size_t size, unsigned int at_flags);
>> long syscall(SYS_file_setat
On February 11, 2025 9:22:47 AM PST, Andrey Albershteyn
wrote:
>From: Andrey Albershteyn
>
>Introduce getfsxattrat and setfsxattrat syscalls to manipulate inode
>extended attributes/flags. The syscalls take parent directory fd and
>path to the child together with struct fsxattr.
>
>This is an al
On January 17, 2025 7:45:02 AM PST, Eugene Syromyatnikov
wrote:
>On Fri, Jan 17, 2025 at 2:03 AM H. Peter Anvin wrote:
>>
>> I link the concept of this patchset, but *please* make it clear in the
>> comments that this does not solve the issue of 64-bit kernel arguments
I link the concept of this patchset, but *please* make it clear in the
comments that this does not solve the issue of 64-bit kernel arguments
on 32-bit systems being ABI specific.
This isn't unique to this patch in any way; the only way to handle it is
by keeping track of each ABI.
On 1/15/2
This would seem like a very good idea. However, it is perhaps important
to realize that it doesn't fully eliminate the problems with 64-bit
arguments on 32-bit ABIs being handled differently (never mind
inconsistencies in system call ABIs etc.) There isn't all that much that
can be done about t
On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle wrote:
>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote:
>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
>> Port access. In a future patch HAS_IOPORT=n will disable compilation of
>> the I/O accessor functions in
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote:
>On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
>> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
>>> Hi Heiko,
>>>
>>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
>>> > On Tue, Feb 14, 202
On July 6, 2022 5:23:31 AM PDT, Borislav Petkov wrote:
>On Tue, Jul 05, 2022 at 04:11:45PM -0700, H. Peter Anvin wrote:
>> What I'm wondering is if we shouldn't be simply instrument *every*
>> invocation, and set the trust to zero if we ever trip it.
>
>I
On July 5, 2022 3:00:04 PM PDT, Borislav Petkov wrote:
>On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote:
>> It's just math. The only variable is your confidence level, i.e. at
>> what level do you decide that the likelihood of pure chance is way
>> smal
On July 5, 2022 12:57:04 PM PDT, Borislav Petkov wrote:
>On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote:
>> Oh, huh. Maybe in that case I should adjust the message to say "consider
>> using `random.trust_cpu=0`," which is the thing that would actually make
>> a security differe
,oprofile-l...@lists.sf.net,linux-s390
,sparclinux
From: h...@zytor.com
Message-ID: <41625f06-d755-4c82-86df-a9415feee...@zytor.com>
On January 7, 2020 12:08:31 AM PST, Arnd Bergmann wrote:
>On Tue, Jan 7, 2020 at 3:05 AM Michael Ellerman
>wrote:
>> Arnd Bergmann writes:
>> > +
>> > +static i
t.h| 18 ++
> 9 files changed, 20 insertions(+), 109 deletions(-)
>
For x86:
Reviewed-by: H. Peter Anvin
It still suffers from the zero-one-infinity rule failure of the compat
architecture as a whole, but that is a very different problem. In this case
"co
On 4/16/19 2:59 AM, Florian Weimer wrote:
> * hpa:
>
>> Using symbol versioning doesn't really help much since the real
>> problem is that struct termios can be passed around in userspace, and
>> the interfaces between user space libraries don't have any
>> versioning. However, my POC code deals w
On 4/15/19 10:22 AM, Adhemerval Zanella wrote:
>>
>> New interfaces are only necessary for the handful of architectures that
>> don't have the speed fields *and* to space to put them in.
>
> Based on your WIP, it seems that both sparc and mips could be adapted.
> Do we still have glibc supported
On 08/27/18 06:11, Peter Zijlstra wrote:
> On Mon, Aug 27, 2018 at 05:26:53AM -0700, H. Peter Anvin wrote:
>
>> _THIS_IP_, however, is completely ill-defined, other than being an
>> address *somewhere* in the same global function (not even necessarily
>> the same fun
On 08/27/18 00:33, Peter Zijlstra wrote:
>
> What problem are we trying to solve? _THIS_IP_ and _RET_IP_ work fine.
> We're 'good' at dealing with text addresses, we use them for call stacks
> and all sorts. Why does this need changing?
>
_RET_IP_ works fine, with the following two caveats:
1.
On 08/26/18 12:30, H. Peter Anvin wrote:
> Here is a full-blown (user space) test program demonstrating the whole
> technique and how to use it.
>
> -hpa
Incidentally, it looks like _RET_IP_ really should be defined as:
/*
* Is there any reason whatsoever to have _RET_IP_
Here is a full-blown (user space) test program demonstrating the whole
technique and how to use it.
-hpa
#include
#include
#define _RET_IP_ ((unsigned long)__builtin_return_address(0))
#define noinline __attribute__((noinline))
#define used __attribute__((used))
/* __always_inline is d
On 08/25/18 20:16, H. Peter Anvin wrote:
> On 08/25/18 19:38, H. Peter Anvin wrote:
>>
>> If it was worthwhile it would make more sense to at least force this
>> into the rodata section with the string, something like the attached
>> file for an example; however, I hav
On 08/25/18 03:48, Helge Deller wrote:
>
> Currently alpha, s390, sparc, sh, c6x, ia64 and parisc provide an
> inline assembly function to get the current instruction pointer.
> As mentioned in an earlier thread, I personally would *prefer* if
> _THIS_IP_ would use those inline assembly instruct
On 08/25/18 19:38, H. Peter Anvin wrote:
>
> If it was worthwhile it would make more sense to at least force this
> into the rodata section with the string, something like the attached
> file for an example; however, I have a hunch it doesn't matter.
>
An even nuttier vers
,Eric Biederman ,Tejun Heo
,Paolo Bonzini ,Andrew Morton
,"Kirill A . Shutemov"
,Lu Baolu
From: h...@zytor.com
Message-ID:
On July 26, 2017 9:24:45 PM GMT+02:00, Brijesh Singh
wrote:
>
>Hi Arnd and David,
>
>On 07/26/2017 05:45 AM, Arnd Bergmann wrote:
>> On Tue, Jul 25, 2017 at 11:51 AM, D
,Thomas Gleixner ,Ingo Molnar
,Chris Zankel ,Max Filippov
,Arnd Bergmann
,x...@kernel.org,linux-al...@vger.kernel.org,linux-snps-...@lists.infradead.org,linux-arm-ker...@lists.infradead.org,linux-hexa...@vger.kernel.org,linux-i...@vger.kernel.org,linux-m...@linux-mips.org,openr...@lists.librecor
wrote:
>On Sat, Mar 04, 2017 at 11:15:17AM -0800, H. Peter Anvin wrote:
>> On 03/04/17 05:05, Russell King - ARM Linux wrote:
>> >>
>> >> +static int futex_atomic_op_inuser(int encoded_op, u32 __user
>*uaddr)
>> >> +{
>> >> + int op =
com>
On March 4, 2017 1:38:05 PM PST, Stafford Horne wrote:
>On Sat, Mar 04, 2017 at 11:15:17AM -0800, H. Peter Anvin wrote:
>> On 03/04/17 05:05, Russell King - ARM Linux wrote:
>> >>
>> >> +static int futex_atomic_op_inuser(int encoded_op, u32 __user
>*ua
On 03/04/17 05:05, Russell King - ARM Linux wrote:
>>
>> +static int futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
>> +{
>> +int op = (encoded_op >> 28) & 7;
>> +int cmp = (encoded_op >> 24) & 15;
>> +int oparg = (encoded_op << 8) >> 20;
>> +int cmparg = (encoded_op <<
,Johannes Weiner ,Alexei Starovoitov
,Arnaldo Carvalho de Melo ,Alexander Shishkin
,Balbir Singh
,Markus Elfring ,"David
S. Miller" ,Nicolas Dichtel
,Andrew Morton
,Konstantin Khlebnikov ,Jiri Slaby
,Cyrill Gorcunov ,Michal Hocko
,Vlastimil Babka ,Dave Hansen
,Greg Kroah-Hartman
,Dan Carp
On 07/28/2015 08:02 AM, Julien Grall wrote:
> Hi all,
>
> This patch series aims to use the memory terminologies described in
> include/linux/mm.h [1] for Linux xen code.
>
> Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
> first support of Xen was for PV. This has
On 08/30/2014 05:47 AM, Paul Bolle wrote:
>
> Obviously, this can only break compiling those libraries, or other
> users. It can't break already compiled binaries. Besides I don't think
> those libraries, etc actually exist. Maximilian mentioned klibc in
> January, but I wasn't able to find a vers
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
>
> I think the whole "removing Alpha EV5" support is basically bonkers. Just
> use set_bit in the tty layer. Alpha will continue to work as well as it
> always has done and you won't design out support for any future processor
> that turns out no
Add a short member for proper alignment and one will probably pop out.
Sent from my tablet, pardon any formatting problems.
> On Sep 8, 2014, at 19:56, James Bottomley
> wrote:
>
>> On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
>> On 09/08/2014 01:50 AM, James Bottomley wrote:
Tw
On 09/08/2014 07:56 PM, James Bottomley wrote:
>>
>> Yeah, the extra requirement I added is basically nonsense, since the
>> only issue is what instructions the compiler is emitting. So if compiler
>> thinks the alignment is natural and combines the writes -- ok. If the
>> compiler thinks the align
On 09/08/2014 03:39 PM, James Bottomley wrote:
>
> I don't understand what you mean by "pass each other". Atomicity
> guarantees are not ordering guarantees in a SMP environment. The
> guarantee is that if you follow the rules when two CPUs update the same
> natural width aligned object simultan
On 09/08/2014 03:43 PM, James Bottomley wrote:
>
> This was years ago (possibly decades). We had to implement in-kernel
> unaligned traps for the networking layer because it could access short
> and int fields that weren't of the correct alignment when processing
> packets. It that's all correct
On 09/08/2014 12:09 PM, James Bottomley wrote:
>
> Um, I think you need to re-read the thread; that's not what I said at
> all. It's even written lower down: "PA can't do atomic bit sets (no
> atomic RMW except the ldcw operation) it can do atomic writes to
> fundamental sizes (byte, short, int, l
On 09/08/2014 12:09 PM, James Bottomley wrote:
>
> Um, I think you need to re-read the thread; that's not what I said at
> all. It's even written lower down: "PA can't do atomic bit sets (no
> atomic RMW except the ldcw operation) it can do atomic writes to
> fundamental sizes (byte, short, int, l
On 09/07/2014 10:56 PM, James Bottomley wrote:
> On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
>> How many PARISC systems do we have that actually do real work on Linux?
>
> I'd be very surprised if this problem didn't exist on all alignment
> requiring
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
> On Fri, 05 Sep 2014 08:41:52 -0700
> "H. Peter Anvin" wrote:
>
>> On 09/05/2014 08:31 AM, Peter Hurley wrote:
>>>
>>> Which is a bit ironic because I remember when Digital had a team
>>&
How many PARISC systems do we have that actually do real work on Linux?
On September 7, 2014 4:36:55 PM PDT, "Paul E. McKenney"
wrote:
>On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote:
>> I'm confused why storing 0x0102 would be a problem. I think gcc
I'm confused why storing 0x0102 would be a problem. I think gcc does that even
on other cpus.
More atomicity can't hurt, can it?
On September 7, 2014 4:00:19 PM PDT, "Paul E. McKenney"
wrote:
>On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
>> On Sun, 2014-09-07 at 09:21 -070
On 09/05/2014 01:14 PM, Peter Hurley wrote:
>
> Here's how I read the two statements.
>
> First, the commit message:
>
> "It [this commit] documents that CPUs [supported by the Linux kernel]
> _must provide_ atomic one-byte and two-byte naturally aligned loads and
> stores."
>
> Second, in the
On 09/05/2014 01:12 PM, Peter Zijlstra wrote:
>>
>> ... and I'm wondering if I should _remove_ pre-EV56 configurations or
>> move the default choice and produce a warning about unsupported Alpha
>> CPUs instead?
>>
>
> depends BROKEN
>
> or is that deprecated?
>
Just rip it out, like I did fo
On 09/05/2014 08:31 AM, Peter Hurley wrote:
>
> Which is a bit ironic because I remember when Digital had a team
> working on emulating native x86 apps on Alpha/NT.
>
Right, because the x86 architecture was obsolete and would never scale...
-hpa
On 09/04/2014 05:59 PM, Peter Hurley wrote:
> I have no idea how prevalent the ev56 is compared to the ev5.
> Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 2116
On 09/04/2014 05:59 PM, Peter Hurley wrote:
> I have no idea how prevalent the ev56 is compared to the ev5.
> Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 2116
On 09/04/2014 12:42 PM, Peter Hurley wrote:
>
> Or we could give up on the Alpha.
>
If Alpha is turning into Voyager (kept alive only as a museum piece, but
actively causing problems) then please let's kill it.
-hpa
___
Linuxppc-dev mailing
On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
>
> Yeah correct, alpha and bytes right ? Is there any other ? That's why I
> suggested int.
>
Even for Alpha it is only the 21064 AFAIK.
-hpa
___
Linuxppc-dev mailing list
Linuxppc-dev@l
s
> like overkill for a patch that mostly deletes code.
>
> Akpm, can you take this?
>
I'm fine with it as-is.
Acked-by: H. Peter Anvin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
David S. Miller"
> CC: sparcli...@vger.kernel.org
> CC: Guan Xuetao
> CC: Ingo Molnar
> CC: Thomas Gleixner
> CC: "H. Peter Anvin"
> CC: x...@kernel.org
Acked-by: H. Peter Anvin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 10/10/2013 03:17 AM, Alexander Gordeev wrote:
> On Wed, Oct 09, 2013 at 03:24:08PM +1100, Benjamin Herrenschmidt wrote:
>
> Ok, this suggestion sounded in one or another form by several people.
> What about name it pcim_enable_msix_range() and wrap in couple more
> helpers to complete an API:
>
On 10/02/2013 03:29 AM, Alexander Gordeev wrote:
>
> As result, device drivers will cease to use the overcomplicated
> repeated fallbacks technique and resort to a straightforward
> pattern - determine the number of MSI/MSI-X interrupts required
> before calling pci_enable_msi_block() and pci_enab
On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
>
> Right, that is what the patch I just posted does.
>
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change
On 05/28/2013 01:19 AM, Ingo Molnar wrote:
>
> So I think the same principle applies to it as to any other debugging
> code: it's fine to be able to turn debugging off. It's a performance
> versus kernel robustness/determinism trade-off.
>
I suspect, rather, that BUG() should turn into a trap
On 03/26/2013 10:56 AM, Yinghai Lu wrote:
>
> For 1 and 2,
>
> Acked-by: Yinghai Lu
>
Similarly:
Acked-by: H. Peter Anvin
-hpa
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
se is stale.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
s it is hard to catch the new ones among the flood.
>>
>
> hpa,
>
> Was this change only needed for x86? If so, could you put that into
> asm/ftrace.h instead?
>
Yes (on both accounts). It was part of the syscall changes; I'll move
the include.
-hpa
--
On 12/04/2011 02:41 PM, Benjamin Herrenschmidt wrote:
>
> I agree with Russell, his approach is a lot easier to maintain long run,
> we should even consider converting existing definitions.
>
Thirded.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work f
On 07/05/2011 07:06 AM, Ohad Ben-Cohen wrote:
> virtio has been so far used only in the context of virtualization,
> and the virtio Kconfig was sourced directly by the relevant arch
> Kconfigs when VIRTUALIZATION was selected.
>
> Now that we start using virtio for inter-processor communications,
On 06/15/2011 12:39 AM, Russell King - ARM Linux wrote:
> On Tue, Jun 14, 2011 at 09:31:27PM -0700, H. Peter Anvin wrote:
>> On 06/14/2011 03:08 PM, Luck, Tony wrote:
>>> I took a look at the back of all my ia64 systems - none of them
>>> have a parallel port. It seem
>> ISA DMA. Conditionalizing this on ISA DMA makes total sense.
>
> No it doesn't. It depends on the ISA DMA API, not that the machine has
> ISA DMA.
>
> I have a platform which has no ISA DMA but uses the floppy driver. Please
> don't break it.
OK, even more ca
On 06/14/2011 09:40 PM, Guenter Roeck wrote:
> On Wed, Jun 15, 2011 at 12:18:36AM -0400, H. Peter Anvin wrote:
>> On 06/14/2011 03:34 PM, Ralf Baechle wrote:
>>>
>>> There is no point in offering to build something that couldn't possibly be
>>> used. It
unlikely that new systems will
> start adding parallel ports :-)
>
> So even if I had a printer (or other device) that used a parallel
> port, I have no way to test it.
>
If it has PCI slots, it can have a parallel port.
-hpa
--
H. Peter Anvin, Intel Open Source Techno
"arch has working
> PC-style inb/outb instructions", so we can build a kernel without them but
> still get MMIO based drivers for PCI-less platforms.
Now, isn't that was iowrite/ioread was designed for?
-hpa
--
H.
hat only exist on ARM and MIPS
SoCs are offered on x86 platforms?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
htt
On 06/14/2011 12:08 PM, Ralf Baechle wrote:
> The PC parallel port Kconfig as acquired one of those messy terms to
> describe it's architecture dependencies:
>
>depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && \
>(!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN
3] for the
> regs_return_value(). I have no idea which one is correct, but this patch now
> uses regs[3].
>
> Signed-off-by: Eric Paris
For the x86 portions:
Acked-by: H. Peter Anvin
-hpa
___
Linuxppc-dev mailing list
Linuxp
TIF_IA32 is set during the execution of a 32-bit system call - so touched on
each compat system call. Is this the actual flag you want? A 32-bit address
space flag is different from TIF_IA32.
--
Sent from my mobile phone. Please pardon any lack of formatting.
Stephen Wilson wrote:
On Thu, Mar
Sorry... I confused them too. It's TS_COMPAT which is problematic.
--
Sent from my mobile phone. Please pardon any lack of formatting.
Stephen Wilson wrote:
On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote: > On Thu, Mar 10,
2011 at 08:00:32AM -0800, Andi Kleen wrote: > > On Tue, Mar
On 10/11/2010 03:33 PM, Thomas Gleixner wrote:
> On Tue, 12 Oct 2010, Benjamin Herrenschmidt wrote:
>
>> On Mon, 2010-10-11 at 13:11 -0700, Tim Pepper wrote:
>>> I'm not necessarily wanting to open up the age old question of "what is
>>> a good HZ", but we were doing some testing on timer tick ove
f course, partly because we *still* don't actually have a
systematic model for argument passing.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 06/23/2010 04:38 AM, Frederic Weisbecker wrote:
>
> I haven't heard any complains about existing syscalls wrappers.
>
Then you truly haven't been listening.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don'
On 06/09/2010 11:14 AM, Sukadev Bhattiprolu wrote:
> |
> | Even for x86, it's an easier API. Callers would be specifying
> | two numbers they already have: the argument and return value
> | for malloc. Currently the numbers must be added together,
> | destroying information, except on hppa (must n
gt;
It should work, because r1, being the stack pointer, is already marked a
reserved register in gcc.
The reference Pavel is citing bascially states that gcc won't globally
reserve the register, which is true, but it is already reserved anyway.
-hpa
--
H. Peter Anvin, Intel Open Source
ou can have a "bum merge" where code conflicts logically,
even if it isn't visible as a conflict in git. Furthermore, of course,
you can have misresolved actual conflicts.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Inte
we probably need to ask the binutils people...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Sam Ravnborg wrote:
> On Fri, May 01, 2009 at 09:33:13AM -0700, H. Peter Anvin wrote:
>> Tim Abbott wrote:
>>> On Fri, 1 May 2009, Sam Ravnborg wrote:
>>>
>>>> On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote:
>>>>> +#define __PAG
?
>
> I believe that is correct.
>
... but that doesn't mean it's the right thing to do.
It's better to be fully explicit when macroizing this kind of stuff.
This is part of why macroizing it is good: it means we end up with *one*
place that determines this stuff, not som
the CMD0 is supposed to be sent at < 400 kHz
since the card will still be in open drain mode at that point.
Does that disagree with your observations? If so, I'd be really
interested to find out what you have seen in more detail, as it adds to
the understanding of MMC/SD cards in the fiel
Michal Simek wrote:
Michal Simek wrote:
I expect it but I haven't information about. I'll check it.
I'm assuming Microblaze doesn't actually add a.out support, does it?
I think that any support were there but I assume that no one use it.
Most other new architectures don't bother, hence the
Michal Simek wrote:
I expect it but I haven't information about. I'll check it.
I'm assuming Microblaze doesn't actually add a.out support, does it?
-hpa
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinf
Arnd Bergmann wrote:
On Thursday 26 June 2008, Adrian Bunk wrote:
The comment could be nuked (as well as the #ifdef __KERNEL__), but for
the one #define an asm-generic header would IMHO be overkill.
I agree that it doesn't technically make sense to have a one-line
asm-generic header, but I lik
Arnd Bergmann wrote:
* You are using sys_ipc and sys_socketcall instead of the
broken-out syscalls, which is a direct consequence of following
the i386 numbering scheme.
Please pretty please kill, kill, kill...
-hpa
___
Linuxppc-dev mailing
Arnd Bergmann wrote:
You still set __NR_fork. There is no point defining the number if you
can't actually call the syscall in the first place.
Worse, it is actively *harmful* to set the number; klibc or anything
that uses similar kinds of scripts for portability will see the symbol
and thin
Kumar Gala wrote:
Sam,
We have a case in powerpc in which we want to link some library routines
with all module objects. The routines are intended for handling
out-of-line function call register save/restore so having them as
EXPORT_SYMBOL() is counter productive (we do also need to link the
Jeremy Fitzhardinge wrote:
>>
>> ENOTTY is so excessively misnamed that it is actually surprising
>> anybody ever got that "right" (for very small values of right i guess)
>
> But it *isn't* a typewriter. Of course, it's not a giraffe either.
>
The union of things that are not typewriters and n
Andi Kleen wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>> For one thing, it looks like we're returning the wrong thing (EINVAL
>> rather than ENOTTY) across the board. This was unfortunately a common
>> misunderstanding with non-tty-related ioct
Geert Uytterhoeven wrote:
>
> Fuse-san discovered that running the umount that's part of busybox on a PS3
> with a recent kernel causes an error message to be printed on the console:
>
> | ioctl32(busybox:1340): Unknown cmd fd(3) cmd(4c01){t:'L';sz:0}
> arg() on /dev/sda1
>
> On ol
87 matches
Mail list logo
