On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote:
> > > There are uses for both. For example today I was updating the tar ball
> > > which is used to create the var file system for a new chroot. I
> > > certainly
> > > want to see corretly setup owner/permissions when I look into
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote:
> > There was a thread a few months ago where file-as-directory was
> > discussed extensively, after Namesys implemented it. That's where the
> > conversation on detachable mount points originated AFAIR. It will
> > probably happen at
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote:
There was a thread a few months ago where file-as-directory was
discussed extensively, after Namesys implemented it. That's where the
conversation on detachable mount points originated AFAIR. It will
probably happen at some
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote:
There are uses for both. For example today I was updating the tar ball
which is used to create the var file system for a new chroot. I
certainly
want to see corretly setup owner/permissions when I look into that tar
On Tue, Apr 12, 2005 at 17:13:03 +0100, Jamie Lokier wrote:
> Miklos Szeredi wrote:
> > > Note that NFS checks the permissions on _both_ the client and server,
> > > for a reason.
> >
> > Does it? If I read the code correctly the client checks credentials
> > supplied by the server (or cached).
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote:
> > Could you explain a little more? I don't see the point in denying
> > access to root, but I also can't tell from your explanation whether you
> > do or not.
>
> Fuse by default does. This can be disabled by one of two mount
>
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote:
Could you explain a little more? I don't see the point in denying
access to root, but I also can't tell from your explanation whether you
do or not.
Fuse by default does. This can be disabled by one of two mount
options:
On Tue, Apr 12, 2005 at 17:13:03 +0100, Jamie Lokier wrote:
Miklos Szeredi wrote:
Note that NFS checks the permissions on _both_ the client and server,
for a reason.
Does it? If I read the code correctly the client checks credentials
supplied by the server (or cached). But the
On Mon, Apr 11, 2005 at 04:56:06 +0200, Marcin Dalecki wrote:
>
> On 2005-04-11, at 04:26, Miles Bader wrote:
>
> >Marcin Dalecki <[EMAIL PROTECTED]> writes:
> >>Better don't waste your time with looking at Arch. Stick with patches
> >>you maintain by hand combined with some scripts containing a
On Mon, Apr 11, 2005 at 04:56:06 +0200, Marcin Dalecki wrote:
On 2005-04-11, at 04:26, Miles Bader wrote:
Marcin Dalecki [EMAIL PROTECTED] writes:
Better don't waste your time with looking at Arch. Stick with patches
you maintain by hand combined with some scripts containing a list of
On Sat, Apr 09, 2005 at 03:01:29 +0200, Marcin Dalecki wrote:
>
> On 2005-04-07, at 09:44, Jan Hudec wrote:
> >
> >I have looked at most systems currently available. I would suggest
> >following for closer look on:
> >
> >1) GNU Arch/Bazaar. They use t
On Sat, Apr 09, 2005 at 03:01:29 +0200, Marcin Dalecki wrote:
On 2005-04-07, at 09:44, Jan Hudec wrote:
I have looked at most systems currently available. I would suggest
following for closer look on:
1) GNU Arch/Bazaar. They use the same archive format, simple, have the
concepts
On Wed, Apr 06, 2005 at 08:42:08 -0700, Linus Torvalds wrote:
> PS. Don't bother telling me about subversion. If you must, start reading
> up on "monotone". That seems to be the most viable alternative, but don't
> pester the developers so much that they don't get any work done. They are
> already
On Wed, Apr 06, 2005 at 08:42:08 -0700, Linus Torvalds wrote:
PS. Don't bother telling me about subversion. If you must, start reading
up on monotone. That seems to be the most viable alternative, but don't
pester the developers so much that they don't get any work done. They are
already aware
On Wed, Mar 09, 2005 at 11:26:30 +0100, Weber Matthias wrote:
> On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote:
> >> is there any chance to signal an EOF when writing data to kernel via proc
> >> fs? >> Actually if the length of data is N*PAGE_SIZE it seems not to be
> >>
On Wed, Mar 09, 2005 at 11:26:30 +0100, Weber Matthias wrote:
On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote:
is there any chance to signal an EOF when writing data to kernel via proc
fs? Actually if the length of data is N*PAGE_SIZE it seems not to be
detectable.
I
On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote:
> is there any chance to signal an EOF when writing data to kernel via proc fs?
> Actually if the length of data is N*PAGE_SIZE it seems not to be detectable.
> I followed up the "struct file" but haven't found anything that helped...
On Tue, Mar 08, 2005 at 20:05:42 +0100, Weber Matthias wrote:
is there any chance to signal an EOF when writing data to kernel via proc fs?
Actually if the length of data is N*PAGE_SIZE it seems not to be detectable.
I followed up the struct file but haven't found anything that helped...
On Fri, Jan 28, 2005 at 20:23:55 -0800, Om wrote:
> On Fri, Jan 28, 2005 at 01:40:51PM -0800, Rock Gordon wrote:
> > Hi everbody,
> >
> > Thanks for your replies.
> >
> > However I think my copy_to_user and copy_from_user are
> > failing since the kernel-mode thread is copying data
> > into
On Fri, Jan 28, 2005 at 20:23:55 -0800, Om wrote:
On Fri, Jan 28, 2005 at 01:40:51PM -0800, Rock Gordon wrote:
Hi everbody,
Thanks for your replies.
However I think my copy_to_user and copy_from_user are
failing since the kernel-mode thread is copying data
into another process's
On Wed, Jun 27, 2001 at 12:35:13AM -0600, Blesson Paul wrote:
> 1: P1 and P2 have different physical areas of memory. This is how
> protection works.
>
> 2: Why do they need to share the same memory? You can have your second
> process
> communicate with your first process through IPC.
>
> 3:
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote:
> At 10:59 AM 6/28/2001 -0400, Dan Maas wrote:
> >life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation
> >into queued, information-carrying siginfo signals just shows how badly we
> >need a more robust event
Hello,
> I am happy that processes in Linux are so marvelous. Linux does not need
> a decent POSIX threads implementation because the same functionality can
> be achived with processes. Do what you like, you write the kernel code.
> I could write my soft using fork special fetaures in Linux.
>
Hello,
I am happy that processes in Linux are so marvelous. Linux does not need
a decent POSIX threads implementation because the same functionality can
be achived with processes. Do what you like, you write the kernel code.
I could write my soft using fork special fetaures in Linux.
But I
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote:
At 10:59 AM 6/28/2001 -0400, Dan Maas wrote:
life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation
into queued, information-carrying siginfo signals just shows how badly we
need a more robust event model...
On Wed, Jun 27, 2001 at 12:35:13AM -0600, Blesson Paul wrote:
1: P1 and P2 have different physical areas of memory. This is how
protection works.
2: Why do they need to share the same memory? You can have your second
process
communicate with your first process through IPC.
3: Linux
RPC over TCP?
For puropose of shool excercise the work saved with RPC might be tha main argument.
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
To unsubscribe from this l
of shool excercise the work saved with RPC might be tha main argument.
- Jan Hudec `Bulb' [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
ets got the 8-bit dma channels handling wrong, but I really
don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting.
- Jan Hudec `Bulb' <[EMAIL
correctly shutdown and closed.
Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked?
(ie. how many bytes were acked).
- Jan Hudec `Bulb' <
the aplication somehow ask the tcp/ip stack what was actualy acked?
(ie. how many bytes were acked).
- Jan Hudec `Bulb' [EMAIL PROTECTED]
-
To unsubscribe from this list: send
wrong, but I really
don't know. Btw: for me 2.2.x autodetected right, 2.4.x need explicit setting.
- Jan Hudec `Bulb' [EMAIL PROTECTED]
-
To unsubscribe from this list
Hi,
When I compiled and booted 2.4.5, the machine got stuck in
ifconfig lo 127.0.0.1
(SysRq still worked, ^C did not seem to).
I tried to strace it. Last thing strace managed to write was:
ioctl(4, 0x8914
(no comma, not including the trird argument). I tried to switch of some
compile-time
Hi,
When I compiled and booted 2.4.5, the machine got stuck in
ifconfig lo 127.0.0.1
(SysRq still worked, ^C did not seem to).
I tried to strace it. Last thing strace managed to write was:
ioctl(4, 0x8914
(no comma, not including the trird argument). I tried to switch of some
compile-time
that's 1) Wrong 2) I need 4 bits ... that's 16 choices.
It's wrong because append is specified in addition to write (for open syscall).
- Jan Hudec `Bulb' <[EMAIL
wrong because append is specified in addition to write (for open syscall).
- Jan Hudec `Bulb' [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
od place. Lookup might do, but it might not do on other
operating systems.
--------
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
.
- Jan Hudec `Bulb' [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
surely makes sence to have a
program with read but without exec permission (though it can be made to
run).
--------
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
To unsubscribe from this l
).
- Jan Hudec `Bulb' [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
advance.
Bulb
- Jan Hudec `Bulb' <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
- Jan Hudec `Bulb' [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Blesson Paul writes:
>
> > This is an another doubt related to VFS. I want to know
> > wheather all files are assigned their inode number at the
> > mounting time itself or inodes are assigned to files upon
> > accessing only
>
> That would depend on what type of filesystem you use.
> For
Blesson Paul writes:
This is an another doubt related to VFS. I want to know
wheather all files are assigned their inode number at the
mounting time itself or inodes are assigned to files upon
accessing only
That would depend on what type of filesystem you use.
For ext2, inode
44 matches
Mail list logo
