All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Soete <joel.soete@freebel.net>
To: Randolph Chung <randolph@tausq.org>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
Date: Sun, 27 Oct 2002 00:32:35 +0000	[thread overview]
Message-ID: <3DBB3423.5020408@freebel.net> (raw)
In-Reply-To: 3DBB30C0.6060000@freebel.net

__pu_err disapear in ..asm64?
It doesn't seems to be an error, so don't we need anymore??

Joel Soete wrote:
> 
> 
> Randolph Chung wrote:
> 
>> In reference to a message from Joel Soete, dated Oct 26:
>>
>>> i386 declare: "extern void __get_user_bad(void);"
>>> ...
>>> but not define elsewhere? (is it there so that the build of the 
>>> kernel failed if that case was requested to run properly?)
>>
>>
>>
>> yes.
>>
>>
>>> PS: afaik on i386 only put_user_u64 is define why not pending get_user?
>>
>>
>>
>> on first glance i haven't found any code that uses get_user with 64-bit
>> quantities.
> 
> 
> Not found too.
> 
>> if you have a specific need for this, please let me know.
> 
> 
> No spefic need, thanks. It was just because mips (32bits) already 
> foreseen it and it would be already complete :)
> 
>>
>> in the mean time, i've checked in support for put_user with 64-bit
>> values. This is in 2.4.19-pa24
> 
> 
> Great, I will test it (in fact I was not so far; just a problem of 
> writing the right way).
> 
> Anyway couldn't we also consider __get_user_bad() and __get_kernel_bad() 
> for _default:_ case (just to avoid erronious case: with the problem 
> encounter with xfs test I was near to loose all my system :(( )?
> 
>>
>> Let me know if this works for you. i've tested it only lightly.
>>
> Just have to wait a few days to test at office.
> 
> Thanks again.
> 
> See you,
>     Joel
> 
> 

  parent reply	other threads:[~2002-10-26 23:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-23  7:30 [parisc-linux] mkfs.xfs (xfsprogs-2.3.5) failled jsoe0708
2002-10-24 17:58 ` [parisc-linux] " Stefan Pfetzing
2002-10-24 18:15   ` Randolph Chung
2002-10-24 18:17     ` Stefan Pfetzing
2002-10-24 19:00       ` Randolph Chung
2002-10-24 23:08         ` Stefan Pfetzing
2002-10-25  6:04         ` jsoe0708
2002-10-25 12:58         ` jsoe0708
2002-10-25 15:09           ` jsoe0708
2002-10-26 17:39             ` Joel Soete
2002-10-26 21:18               ` Randolph Chung
     [not found]                 ` <3DBB30C0.6060000@freebel.net>
2002-10-27  0:32                   ` Joel Soete [this message]
2002-10-26 23:40               ` Joel Soete
2002-10-25 15:26           ` Randolph Chung
2002-10-25  5:57   ` jsoe0708

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DBB3423.5020408@freebel.net \
    --to=joel.soete@freebel.net \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=randolph@tausq.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.