On Wed, Dec 03, 2014 at 04:22:33AM -0500, Richard Yao wrote:
> On 12/02/2014 12:26 PM, Greg Kroah-Hartman wrote:
> > On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
> >> Assuming that this dance succeeds, the FUSE process could then make a
> >> readonly file in itself, open it read
On 12/02/2014 12:26 PM, Greg Kroah-Hartman wrote:
> On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
>> Assuming that this dance succeeds, the FUSE process could then make a
>> readonly file in itself, open it read only, unlink it, put the data into
>> the file and send the file
On 12/02/2014 12:26 PM, Greg Kroah-Hartman wrote:
On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
Assuming that this dance succeeds, the FUSE process could then make a
readonly file in itself, open it read only, unlink it, put the data into
the file and send the file descriptor
On Wed, Dec 03, 2014 at 04:22:33AM -0500, Richard Yao wrote:
On 12/02/2014 12:26 PM, Greg Kroah-Hartman wrote:
On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
Assuming that this dance succeeds, the FUSE process could then make a
readonly file in itself, open it read only,
On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
> Assuming that this dance succeeds, the FUSE process could then make a
> readonly file in itself, open it read only, unlink it, put the data into
> the file and send the file descriptor via UNIX domain socket while
> refusing further
On Tue, Dec 02, 2014 at 02:59:21AM -0500, Richard Yao wrote:
> On 12/02/2014 12:48 AM, Greg Kroah-Hartman wrote:
> > On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:
> They regard a userland compatibility shim in the systemd repostory to
> provide
> backward
Dear Greg,
I had hoped that I could avoid reading through the code for yet another
IPC mechanism when I asked why we needed kdbus at LinuxCon Europe. In
hindsight, I should have just checked out the code and read it instead
of asking. However, what I did instead was ask and then do some thinking
On 12/02/2014 12:48 AM, Greg Kroah-Hartman wrote:
> On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:
They regard a userland compatibility shim in the systemd repostory to
provide
backward compatibility for applications. Unfortunately, this is
insufficient to
On 12/02/2014 12:48 AM, Greg Kroah-Hartman wrote:
On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:
They regard a userland compatibility shim in the systemd repostory to
provide
backward compatibility for applications. Unfortunately, this is
insufficient to
ensure compatibility
Dear Greg,
I had hoped that I could avoid reading through the code for yet another
IPC mechanism when I asked why we needed kdbus at LinuxCon Europe. In
hindsight, I should have just checked out the code and read it instead
of asking. However, what I did instead was ask and then do some thinking
On Tue, Dec 02, 2014 at 02:59:21AM -0500, Richard Yao wrote:
On 12/02/2014 12:48 AM, Greg Kroah-Hartman wrote:
On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:
They regard a userland compatibility shim in the systemd repostory to
provide
backward compatibility for
On Tue, Dec 02, 2014 at 07:22:11AM -0500, Richard Yao wrote:
Assuming that this dance succeeds, the FUSE process could then make a
readonly file in itself, open it read only, unlink it, put the data into
the file and send the file descriptor via UNIX domain socket while
refusing further
On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:
> >> They regard a userland compatibility shim in the systemd repostory to
> >> provide
> >> backward compatibility for applications. Unfortunately, this is
> >> insufficient to
> >> ensure compatibility because dependency trees have
On 11/29/2014 12:59 PM, Greg Kroah-Hartman wrote:
> On Sat, Nov 29, 2014 at 06:34:16AM +, Richard Yao wrote:
>> I had the opportunity at LinuxCon Europe to chat with Greg and some other
>> kdbus
>> developers. A few things stood out from our conversation that I thought I
>> would
>> bring to
On 12/01/2014 09:23 AM, One Thousand Gnomes wrote:
>> told quite plainly that such distributions are not worth consideration. If
>> kdbus
>> is merged despite concerns about security and backward compatibility, could
>> we
>> at least have the shim moved to libc netural place, like Linus' tree?
> told quite plainly that such distributions are not worth consideration. If
> kdbus
> is merged despite concerns about security and backward compatibility, could we
> at least have the shim moved to libc netural place, like Linus' tree?
I would expect any other libc would fork the shim anyway
On 12/01/2014 09:23 AM, One Thousand Gnomes wrote:
told quite plainly that such distributions are not worth consideration. If
kdbus
is merged despite concerns about security and backward compatibility, could
we
at least have the shim moved to libc netural place, like Linus' tree?
I would
On 11/29/2014 12:59 PM, Greg Kroah-Hartman wrote:
On Sat, Nov 29, 2014 at 06:34:16AM +, Richard Yao wrote:
I had the opportunity at LinuxCon Europe to chat with Greg and some other
kdbus
developers. A few things stood out from our conversation that I thought I
would
bring to the list
On Tue, Dec 02, 2014 at 12:40:09AM -0500, Richard Yao wrote:
They regard a userland compatibility shim in the systemd repostory to
provide
backward compatibility for applications. Unfortunately, this is
insufficient to
ensure compatibility because dependency trees have multiple levels.
told quite plainly that such distributions are not worth consideration. If
kdbus
is merged despite concerns about security and backward compatibility, could we
at least have the shim moved to libc netural place, like Linus' tree?
I would expect any other libc would fork the shim anyway (or
On Sat, Nov 29, 2014 at 06:34:16AM +, Richard Yao wrote:
> I had the opportunity at LinuxCon Europe to chat with Greg and some other
> kdbus
> developers. A few things stood out from our conversation that I thought I
> would
> bring to the list for discussion.
Any reason why you didn't
On Sat, Nov 29, 2014 at 06:34:16AM +, Richard Yao wrote:
I had the opportunity at LinuxCon Europe to chat with Greg and some other
kdbus
developers. A few things stood out from our conversation that I thought I
would
bring to the list for discussion.
Any reason why you didn't respond
it and that includes its own components (aside
from its pid 1). The systemd project wanting the API is not a valid reason for
why it should be in the kernel, although it could be a reason to make a CUSE
version go into systemd's pid 1.
That said, why not make kdbus use CUSE?
P.S. I also mentioned my concern
it and that includes its own components (aside
from its pid 1). The systemd project wanting the API is not a valid reason for
why it should be in the kernel, although it could be a reason to make a CUSE
version go into systemd's pid 1.
That said, why not make kdbus use CUSE?
P.S. I also mentioned my concern
24 matches
Mail list logo
