On Fri, Sep 20, 2013 at 8:00 AM, H. Peter Anvin wrote:
> On 09/20/2013 04:27 AM, Matt Fleming wrote:
>> On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
>>> Would it be acceptable to fix the naming/comments, and convert values
>>> above 126 to '?'
>>> in the current patchset, and address a more
On Fri, Sep 20, 2013 at 8:00 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/20/2013 04:27 AM, Matt Fleming wrote:
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
Would it be acceptable to fix the naming/comments, and convert values
above 126 to '?'
in the current patchset, and address a more
On 09/20/2013 04:27 AM, Matt Fleming wrote:
> On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
>> Would it be acceptable to fix the naming/comments, and convert values
>> above 126 to '?'
>> in the current patchset, and address a more thorough fix in another patch
>> set?
>> The ARM and ARM64 EFI
On Fri, 20 Sep, at 01:02:41AM, Adam Borowski wrote:
> Are we on the same page so far? If so, I can make a patch atop yours.
Patches to fix this would be most welcome, though I'd wait until Roy
sends out another version of this patch with the name/comment changes.
This series will eventually end
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
> Would it be acceptable to fix the naming/comments, and convert values
> above 126 to '?'
> in the current patchset, and address a more thorough fix in another patch set?
> The ARM and ARM64 EFI stub patchsets that are mostly complete depend
> on
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
Would it be acceptable to fix the naming/comments, and convert values
above 126 to '?'
in the current patchset, and address a more thorough fix in another patch set?
The ARM and ARM64 EFI stub patchsets that are mostly complete depend
on this
On Fri, 20 Sep, at 01:02:41AM, Adam Borowski wrote:
Are we on the same page so far? If so, I can make a patch atop yours.
Patches to fix this would be most welcome, though I'd wait until Roy
sends out another version of this patch with the name/comment changes.
This series will eventually end
On 09/20/2013 04:27 AM, Matt Fleming wrote:
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
Would it be acceptable to fix the naming/comments, and convert values
above 126 to '?'
in the current patchset, and address a more thorough fix in another patch
set?
The ARM and ARM64 EFI stub
On Wed, Sep 18, 2013 at 09:48:44PM -0700, Roy Franz wrote:
> On Wed, Sep 18, 2013 at 8:44 PM, Adam Borowski wrote:
> > [UCS2 truncation]
>
> I stuck to re-arranging the code that was there, as I don't know enough
> about character encodings to propose changes.
I on the other hand don't know the
On Wed, Sep 18, 2013 at 09:48:44PM -0700, Roy Franz wrote:
On Wed, Sep 18, 2013 at 8:44 PM, Adam Borowski kilob...@angband.pl wrote:
[UCS2 truncation]
I stuck to re-arranging the code that was there, as I don't know enough
about character encodings to propose changes.
I on the other hand
On Wed, Sep 18, 2013 at 8:44 PM, Adam Borowski wrote:
> On Mon, Sep 16, 2013 at 09:11:25PM -0700, Roy Franz wrote:
>> +/* Convert the unicode UEFI command line to ASCII to pass to kernel.
>> + * Size of memory allocated return in *cmd_line_len.
>> + * Returns NULL on error.
>> + */
>> +static
On 09/18/2013 10:44 PM, Adam Borowski wrote:
>
> In fact, these days it's 8-bit encodings that are more likely to be Unicode
> than 16-bit ones: UTF-8 is ubiquitous, while you usually get UCS2 at most.
> In either case, though, we have here is a 7-bit charset encoded as either
> 8-bit or 16-bit
On Mon, Sep 16, 2013 at 09:11:25PM -0700, Roy Franz wrote:
> +/* Convert the unicode UEFI command line to ASCII to pass to kernel.
> + * Size of memory allocated return in *cmd_line_len.
> + * Returns NULL on error.
> + */
> +static char *efi_convert_cmdline_to_ascii(efi_system_table_t
On Mon, Sep 16, 2013 at 09:11:25PM -0700, Roy Franz wrote:
+/* Convert the unicode UEFI command line to ASCII to pass to kernel.
+ * Size of memory allocated return in *cmd_line_len.
+ * Returns NULL on error.
+ */
+static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
On 09/18/2013 10:44 PM, Adam Borowski wrote:
In fact, these days it's 8-bit encodings that are more likely to be Unicode
than 16-bit ones: UTF-8 is ubiquitous, while you usually get UCS2 at most.
In either case, though, we have here is a 7-bit charset encoded as either
8-bit or 16-bit units.
On Wed, Sep 18, 2013 at 8:44 PM, Adam Borowski kilob...@angband.pl wrote:
On Mon, Sep 16, 2013 at 09:11:25PM -0700, Roy Franz wrote:
+/* Convert the unicode UEFI command line to ASCII to pass to kernel.
+ * Size of memory allocated return in *cmd_line_len.
+ * Returns NULL on error.
+ */
16 matches
Mail list logo
