On Fri, Apr 24, 2015 at 10:52 AM, Linus Torvalds
wrote:
>
> So even today, by all means make your protocols or disk images use
> big-endian byte formats. But do it unconditionally. Don't make the
> mistake of encoding the byte order as part of the data, and then
> dynamically switching things (or
On Fri, Apr 24, 2015 at 7:32 AM, Olaf Hering wrote:
> On Wed, Apr 22, Linus Torvalds wrote:
>
>> Conditional byte order is worse than silly - it's terminally stupid.
>
>> In other words, think networking, which statically just decided to use
>> big-endian. Sure, that was the wrong choice in the en
On Fri, Apr 24, 2015 at 05:02:32PM +0200, Olaf Hering wrote:
> On Fri, Apr 24, Michele Curti wrote:
>
> > http://www.barrgroup.com/Embedded-Systems/How-To/Big-Endian-Little-Endian
> > "Serious run-time performance penalties occur when using TCP/IP on a little
> > endian processor."
>
> This URL l
On Fri, Apr 24, Jiri Kosina wrote:
> Becase the architecture that is running on overwhelming majority of
> today's world computers is little-endian, and therefore has to convert all
> the time.
There is no swap-on-load/store to compensate for the odd decision?
Olaf
--
To unsubscribe from this
On Fri, Apr 24, Michele Curti wrote:
> http://www.barrgroup.com/Embedded-Systems/How-To/Big-Endian-Little-Endian
> "Serious run-time performance penalties occur when using TCP/IP on a little
> endian processor."
This URL lacks the numbers to proof such claim.
Olaf
--
To unsubscribe from this lis
On Fri, 24 Apr 2015, Olaf Hering wrote:
> > Conditional byte order is worse than silly - it's terminally stupid.
>
> > In other words, think networking, which statically just decided to use
> > big-endian. Sure, that was the wrong choice in the end, but even
>
> Why was that wrong? Any pointers
On Fri, Apr 24, 2015 at 04:32:12PM +0200, Olaf Hering wrote:
> On Wed, Apr 22, Linus Torvalds wrote:
>
> > Conditional byte order is worse than silly - it's terminally stupid.
>
> > In other words, think networking, which statically just decided to use
> > big-endian. Sure, that was the wrong cho
On Wed, Apr 22, Linus Torvalds wrote:
> Conditional byte order is worse than silly - it's terminally stupid.
> In other words, think networking, which statically just decided to use
> big-endian. Sure, that was the wrong choice in the end, but even
Why was that wrong? Any pointers to further det
On Wed, Apr 22, 2015 at 04:02:34PM -0400, Havoc Pennington wrote:
> On Wed, Apr 22, 2015 at 10:35 AM, Michele Curti
> wrote:
> >
> > Just out of curiosity, would you like to change something in dbus design,
> > if you didn't have to worry about ABI breaks and the like?
> >
>
> Good question. I c
On Wed, Apr 22, 2015 at 5:48 PM, Linus Torvalds
wrote:
>
> Conditional byte order is worse than silly - it's terminally stupid.
>
Hey, usually I write a long rant myself, but I was trying to keep it
to one bullet point for once in my life. Way to ruin it, geez.
Havoc
--
To unsubscribe from this
On Wed, Apr 22, 2015 at 1:02 PM, Havoc Pennington wrote:
> * the byte order marker in every message is silly
It's worse than that.
Conditional byte order is worse than silly - it's terminally stupid.
This is not a "per connection" thing or a "every message"; thing. It's
more fundamental than t
On Wed, Apr 22, 2015 at 10:35 AM, Michele Curti wrote:
>
> Just out of curiosity, would you like to change something in dbus design,
> if you didn't have to worry about ABI breaks and the like?
>
Good question. I can't remember any big-picture things, I'm sure the
current maintainers and users ha
Hi Havoc.
On Wed, Apr 22, 2015 at 09:27:56AM -0400, Havoc Pennington wrote:
>
> If we say it isn't "general purpose" we could mean more than one thing -
>
> - it's a complete system / batteries-included, with a defined
> protocol, vs. a "make your own protocol" kit
> - it isn't especially approp
On 2015-04-22 09:07, Greg Kroah-Hartman wrote:
On Wed, Apr 22, 2015 at 07:40:25AM -0400, Austin S Hemmelgarn wrote:
On 2015-04-21 22:32, Linus Torvalds wrote:
On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski wrote:
If kdbus were a general purpose IPC tool
.. but it's not ..
Except, II
Hi
On Wed, Apr 22, 2015 at 5:19 AM, Andy Lutomirski wrote:
> Where do you draw the line?
User-space draws _this_ line.
A bus creator can set the "mandatory metadata mask" of a bus. It
defines a mask all senders (!) have to use as base. The bus creator
can thus mandate a policy for its bus and f
On Wed, Apr 22, 2015 at 7:40 AM, Austin S Hemmelgarn
wrote:
> Except, IIRC, that was one of the stated design goals in the original patch
> set. I'm pretty sure that i remember a rather verbose exposition that
> pretty much could be summarized as "Linux has no general purpose IPC in the
> kernel,
On Wed, Apr 22, 2015 at 07:40:25AM -0400, Austin S Hemmelgarn wrote:
> On 2015-04-21 22:32, Linus Torvalds wrote:
> >On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski wrote:
> >>
> >>If kdbus were a general purpose IPC tool
> >
> > .. but it's not ..
> >
>
> Except, IIRC, that was one of the stat
Hi
On Wed, Apr 22, 2015 at 3:30 AM, Linus Torvalds
wrote:
> On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
> wrote:
>> - There is a well defined translation of capability bits between user
>> namespaces kdbus does not perform that translation.
>
> Now this looks like a big oversight, and s
On 2015-04-21 22:32, Linus Torvalds wrote:
On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski wrote:
If kdbus were a general purpose IPC tool
.. but it's not ..
Except, IIRC, that was one of the stated design goals in the original
patch set. I'm pretty sure that i remember a rather verb
> > - Access to the capability bits is guarded with PTRACE_MAY_READ
> > kdbus does not honor that and thus leaks information.
>
> Now, this is likely not a real problem.
>
> Yes, when you try to read other processes capabilities, you need
> PTRACE_MAY_READ to see them. HOWEVER, that's not reall
On Tue, Apr 21, 2015 at 7:32 PM, Linus Torvalds
wrote:
> On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski wrote:
>>
>> If kdbus were a general purpose IPC tool
>
> .. but it's not ..
>
>> and if the libraries would
>> expose nice knobs like "set this flag if a
On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski wrote:
>
> If kdbus were a general purpose IPC tool
.. but it's not ..
> and if the libraries would
> expose nice knobs like "set this flag if and only if you want to
> assert CAP_WHATEVER to the server", then
On Tue, Apr 21, 2015 at 6:30 PM, Linus Torvalds
wrote:
> On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
> wrote:
>> - Access to the capability bits is guarded with PTRACE_MAY_READ
>> kdbus does not honor that and thus leaks information.
>
> Now, this is likely not a real problem.
>
> Yes, w
On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
wrote:
>
> - The userspace interface for capability bits has a version number that
> determines the quantity and the meaning of the bits, kdbus does not
> pass that number to userspace.
Well, realistically, we'll just have to freeze the versi
Greg Kroah-Hartman writes:
> On Mon, Apr 13, 2015 at 07:19:49PM -0500, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> > And the code that transfers the meta-data is wrong.
>>
>> In fact it is worse than I thought.
>
> Please see the email response I just wro
25 matches
Mail list logo
