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 06/04/2014 12:24 PM, Arnd Bergmann wrote:
>
> For other timekeeping stuff in the kernel, I agree that using some
> 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds,
> ...) has advantages, that's exactly the point I was making earlier
> against simply extending the internal
On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
>>
>> The bit that is really going to hurt is every single ioctl that uses a
>> timespec.
>>
>> Honestly, though, I really don't understand the point with "struct
>> inode_time". It seems like the zeroeth-order thing is to change the
>> kernel internal
On 06/02/2014 12:19 PM, Arnd Bergmann wrote:
> On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote:
>> On Fri, 30 May 2014, Arnd Bergmann wrote:
>>
>>> a) is this the right approach in general? The previous discussion
>>>pointed this way, but there may be other opinions.
>>
>> The syscall cha
Typically they are using 64-bit signed seconds.
On May 31, 2014 11:22:37 AM PDT, Richard Cochran
wrote:
>On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
>>
>> It's an approximation:
>
>(Approximately never ;)
>
>> with 64-bit timestamps, you can represent close to 300 billion
>>
On 10/30/2013 12:28 PM, Joseph Salisbury wrote:
> Hi Bernd,
>
> The bug reporter confirms that your patch fixes the bug. Any chance
> this patch can make it into 3.12?
FWIW, I don't think reverting the WRITE SAME patch is an option -- it
causes serious filesystem failures.
-hpa
--
To u
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
Don't worry... I have lived in that world for decades... it's a lot like BIOS.
James Bottomley wrote:
>On Tue, 2013-01-22 at 11:05 -0600, H. Peter Anvin wrote:
>> On 01/22/2013 09:43 AM, Alan Stern wrote:
>> > On Tue, 22 Jan 2013, Oliver Neukum wrote:
>> >
On 01/22/2013 09:43 AM, Alan Stern wrote:
> On Tue, 22 Jan 2013, Oliver Neukum wrote:
>
>> On Tuesday 22 January 2013 11:05:35 James Bottomley wrote:
May 3 18:19:06 relampago3 kernel: [ 3948.472796] sd 7:0:0:0: [sdf]
1565565872 512-byte logical blocks: (801 GB/746 GiB)
>>>
>>> This look
James Bottomley wrote:
On Wed, 2007-02-28 at 17:28 -0800, H. Peter Anvin wrote:
James Bottomley wrote:
On Wed, 2007-02-28 at 12:42 -0500, Martin K. Petersen wrote:
4104. It's 8 bytes per hardware sector. At least for T10...
Er ... that won't look good to the 512 ATA compatibility
James Bottomley wrote:
On Wed, 2007-02-28 at 12:42 -0500, Martin K. Petersen wrote:
4104. It's 8 bytes per hardware sector. At least for T10...
Er ... that won't look good to the 512 ATA compatibility remapping ...
Well, in that case you'd only see 8x512 data bytes, no metadata...
Theodore Tso wrote:
In any case, the reason why I bring this up is that it would be really
nice if there was a way with a single laptop drive to be able to do
snapshots and background fsck's without having to use initrd's with
device mapper.
This is a major part of why I've been trying to pus
Andreas Dilger wrote:
And clearing this list when the sector is overwritten, as it will almost
certainly be relocated at the disk level.
Certainly if the overwrite is successful.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [E
Ric Wheeler wrote:
We still have the following challenges:
(1) read-ahead often means that we will retry every bad sector at
least twice from the file system level. The first time, the fs read
ahead request triggers a speculative read that includes the bad sector
(triggering the error ha
Eric W. Biederman wrote:
- Removal of sys_sysctl support where people had used conflicting sysctl
numbers. Trying to break glibc or other applications by changing the
ABI is not cool. 9 instances of this in the kernel seems a little
extreme.
It would be highly advantageous if we could
16 matches
Mail list logo