netnice-kernels — a ML for netnice kernel module and its porting

Re: [Netnice-kernels] Linux NNFS API nearing completion

[Scott B. <sco...@ve...>]

Hi,

I have submitted my changes to fix the rmdir and follow_link
operations to CVS.  In /nnfs/network the control files can no longer
be removed, and rmdir will remove a vif interface.  I have submitted
the original follow_link that I talked about previously because it
conforms to the way symbolic links work on linux.


Scott Brumbaugh

Re: [Netnice-kernels] Linux NNFS API nearing completion

[Scott B. <sco...@ve...>]

On Thu, 28 Oct 2004, Takashi Okumura wrote:

> thanks. it is interesting that output of pwd is a bit differs from FreeBSD'pwd.
> in this case, FreeBSD will show
> 
> 	$ cd /nnfs/procs/1911/sockets/3/
> 	$ ls
> 	lo eth1
> 	$ cd lo
> 	$ pwd
> 	/nnfs/network/lo/vif1
> 
> anyway. your operation (follow_link?) also looks fine. this is okay. thanks.
>

Yes, I will try and fix this. I think I need to change the way I use the 
Linux vfs internal function vfs_follow_link.

 

> > >  - Directory: /nnfs/network/lo
> > >
> > >         mkdir of VIF dir:               OK
> > >         rmdir of VIF dir:               NG?
> > >                 directory not empty error.
> > >

> 
> this operation suggests that we can remove the files under vif1, right?
> which does not make sense to me, since we cannot remove such properties
> from a VIF. on FreeBSD, we implemented that rmdir can simply remove
> the entire VIF directory. exception is that, if the VIF has a child VIF.
> is is hard to implement that way on linux??
> 

This makes sense.  I will try and fix rmdir to work this way.


Thanks,

Scott Brumbaugh

Re: [Netnice-kernels] Linux NNFS API nearing completion

[Takashi O. <ta...@cs...>]

hi scott,

i just simply listed what i found and did not find in the version.
that might have been inappropriate, considering your previous messages...

anyway. it seems like you have already fixed most of the problems.

my comments follow.


Scott Brumbaugh wrote:
> 
> In summary, I added the rmdir and follow_link opperations.
> 
> On Thu, 28 Oct 2004, Takashi Okumura wrote:
> 
> > hi scott,
> >
> >  - Directory: /nnfs/procs/[pid]
> 
> This I would offer to change in the future.

okay.

> >  - Directory: /nnfs/procs/[pid]/*
> >
> > this issue is not serious, but, you will add other control files, right?
> > since priority of this part is low, we may skip this part, for now, also.
> >
> 
> Also, this I did not change as I _think_ all the required control files
> are under Linux /proc.

regarding the process-dependent directories, it is totally okay with
me to leave them, as is, for now. this is because they are not required
for VIF functionality, as you said. but, if time permits, we may have
"cmdline" and "status", in the future, so that libnetnice may operate
on such information.

> >  - Directory: /nnfs/procs/[pid]/*/sockets/
> >
> > cann't we cd to the link?
> >
> >       $ cd lo
> >       lo: Not a directory
> >       $
> >
> 
> I fixed this. I have added the follow_link operation to the
> per-process and per-socket vif symlinks so now you can do this:
> 
> [root@tamarack root]# mkdir /nnfs/network/lo/vif1
> [root@tamarack root]# cd /nnfs/procs/1911/sockets/3/lo/vif1/
> [root@tamarack vif1]# ls
> bandwidth  drops  filter  port  recv  send  type  weight
> [root@tamarack vif1]# pwd
> /nnfs/procs/1911/sockets/3/lo/vif1
> [root@tamarack vif1]#

thanks. it is interesting that output of pwd is a bit differs from FreeBSD'pwd.
in this case, FreeBSD will show

	$ cd /nnfs/procs/1911/sockets/3/
	$ ls
	lo eth1
	$ cd lo
	$ pwd
	/nnfs/network/lo/vif1

anyway. your operation (follow_link?) also looks fine. this is okay. thanks.

> >  - Directory: /nnfs/network/lo
> >
> > i tried parameter setting under lo directory. is this expected behavior?
> > i felt it is not, though i also felt it is easy to fix.
> >
> >                 $ cat type
> >                 Non Work Conserving
> >
> >                 $ echo 1 > type; cat type
> >                 Block
> >
> 
> I believe this happens due to how 'echo' works on Linux.  This will
> also happen on FreeBSD if the value 1 is passed to the os as '1\n'
> Here, echo is adding a '\n' character to the string.  By using 'echo
> -n' the correct value is parsed:

interesting. thanks for the clarification.

> >  - Directory: /nnfs/network/lo
> >
> >         mkdir of VIF dir:               OK
> >         rmdir of VIF dir:               NG?
> >                 directory not empty error.
> >
> 
> I have fixed this.  I have added a stubbed out rmdir operation that
> allows you to do rm -r on a created vif.  However, remember that the
> vif is not removed internally, the directory is just removed from the
> filesystem:

i understand this (we need to fix vif removal code in vif_*.c).

but, i have one question.

> [root@tamarack lo]# pwd
> /nnfs/network/lo
> [root@tamarack lo]# mkdir vif1
> [root@tamarack lo]# ls vif1/
> bandwidth  drops  filter  port  recv  send  type  weight
> [root@tamarack lo]# rmdir vif1/
> rmdir: `vif1/': Directory not empty
> [root@tamarack lo]# rm -ri vif1/
> rm: descend into directory `vif1/'? y
> rm: remove regular empty file `vif1//filter'? y
> rm: remove regular empty file `vif1//port'? y
> rm: remove regular empty file `vif1//drops'? y
> rm: remove regular empty file `vif1//send'? y
> rm: remove regular empty file `vif1//recv'? y
> rm: remove regular empty file `vif1//weight'? y
> rm: remove regular empty file `vif1//bandwidth'? y
> rm: remove regular empty file `vif1//type'? y
> rm: remove directory `vif1/'? y
> [root@tamarack lo]#

this operation suggests that we can remove the files under vif1, right?
which does not make sense to me, since we cannot remove such properties
from a VIF. on FreeBSD, we implemented that rmdir can simply remove
the entire VIF directory. exception is that, if the VIF has a child VIF.
is is hard to implement that way on linux??


> >  - Kernel build
> >
> >       can we merge CONFIG_NNFS and CONFIG_NETNICE?
> >       or, do you think we may leave them, for now?
> >       on FreeBSD, we merged the options.
> >       what do you recommend?
> >
> 
> This I can do in the future.

okay. i understand the statement you wrote in the other message.

> >  - net/core/vif_subr.c
> >
> >       we completely rewritten vif_rm(). we'll need to fix this,
> >       based on net/vif_suvr.c of FreeBSD5.3.
> >
> 
> This I can do in the future.

that is fine.


thanks!!

-- taka

Re: [Netnice-kernels] Linux NNFS API nearing completion

[Scott B. <sco...@ve...>]

Hi Takashi,

I previously replied to your message on the mailing-list and since
then have done more in-depth looking at these issues.  Some of them I
have fixed now and the rest I would offer to fix in the future.  I
think the problem with the 'type' control file is a bug in
nnfs_netnice.c that does not take into account that a string can end
in '\n'.

In summary, I added the rmdir and follow_link opperations.


On Thu, 28 Oct 2004, Takashi Okumura wrote:

> hi scott,
>
>  - Directory: /nnfs/procs/[pid]

This I would offer to change in the future.

>  - Directory: /nnfs/procs/[pid]/*
> 
> this issue is not serious, but, you will add other control files, right?
> since priority of this part is low, we may skip this part, for now, also.
> 

Also, this I did not change as I _think_ all the required control files 
are under Linux /proc.

>  - Directory: /nnfs/procs/[pid]/*/sockets/
> 
> cann't we cd to the link?
> 
> 	$ cd lo
> 	lo: Not a directory
> 	$
> 

I fixed this. I have added the follow_link operation to the
per-process and per-socket vif symlinks so now you can do this:

[root@tamarack root]# mkdir /nnfs/network/lo/vif1
[root@tamarack root]# cd /nnfs/procs/1911/sockets/3/lo/vif1/
[root@tamarack vif1]# ls
bandwidth  drops  filter  port  recv  send  type  weight
[root@tamarack vif1]# pwd
/nnfs/procs/1911/sockets/3/lo/vif1
[root@tamarack vif1]#


>  - Directory: /nnfs/network/lo
> 
> i tried parameter setting under lo directory. is this expected behavior?
> i felt it is not, though i also felt it is easy to fix.
> 
>                 $ cat type
>                 Non Work Conserving
> 
>                 $ echo 1 > type; cat type
>                 Block
> 

I believe this happens due to how 'echo' works on Linux.  This will
also happen on FreeBSD if the value 1 is passed to the os as '1\n'
Here, echo is adding a '\n' character to the string.  By using 'echo
-n' the correct value is parsed:

[root@tamarack root]# cd /nnfs/network/lo/vif1/
[root@tamarack vif1]# cat type
Non Work-Conserving
[root@tamarack vif1]# echo 1 > type; cat type
Block
[root@tamarack vif1]# echo -n 1 > type; cat type
Weighted Fair Queuing
[root@tamarack vif1]#


>  - Directory: /nnfs/network/lo
> 
>         mkdir of VIF dir:               OK
>         rmdir of VIF dir:               NG?
>                 directory not empty error.
> 

I have fixed this.  I have added a stubbed out rmdir operation that
allows you to do rm -r on a created vif.  However, remember that the
vif is not removed internally, the directory is just removed from the
filesystem:

[root@tamarack lo]# pwd
/nnfs/network/lo
[root@tamarack lo]# mkdir vif1
[root@tamarack lo]# ls vif1/
bandwidth  drops  filter  port  recv  send  type  weight
[root@tamarack lo]# rmdir vif1/
rmdir: `vif1/': Directory not empty
[root@tamarack lo]# rm -ri vif1/
rm: descend into directory `vif1/'? y
rm: remove regular empty file `vif1//filter'? y
rm: remove regular empty file `vif1//port'? y
rm: remove regular empty file `vif1//drops'? y
rm: remove regular empty file `vif1//send'? y
rm: remove regular empty file `vif1//recv'? y
rm: remove regular empty file `vif1//weight'? y
rm: remove regular empty file `vif1//bandwidth'? y
rm: remove regular empty file `vif1//type'? y
rm: remove directory `vif1/'? y
[root@tamarack lo]#

>  - Kernel build
> 
> 	can we merge CONFIG_NNFS and CONFIG_NETNICE?
> 	or, do you think we may leave them, for now?
> 	on FreeBSD, we merged the options.
> 	what do you recommend?
> 

This I can do in the future.

>  - net/core/vif_subr.c
> 
> 	we completely rewritten vif_rm(). we'll need to fix this,
> 	based on net/vif_suvr.c of FreeBSD5.3.
> 

This I can do in the future.


Thanks,


Scott Brumbaugh

Re: [Netnice-kernels] Linux NNFS API nearing completion

[Scott B. <sco...@ve...>]

On Thu, 28 Oct 2004, Takashi Okumura wrote:

> hi scott,
> 
> here is my feedback. i checked out the code this afternoon, and used VMware.
> it took me quite long to configure the system, since i'm novice at linux.
> i updated the wiki based on my experience and put a short note about how
> to configure the Linux/Netnice. if you guys have anything to add, or 
> anything you want to modify, please feel free to make any change.
> 
> overall, i was impressed by the implementation. it is working!
> my feedback follows. 
> 

Thanks for the good credit.  I have enjoyed working on this project
and have learned a lot.  I have done this work a quickly as I could
trying to get the basic API features working in one month.


>  - Directory: /nnfs/procs/[pid]
>                
> is it easy to change the directory for the process-dependent files to
> the location, /nnfs/[pid]? this is just to keep the comatibility between
> implementations. if it is too time consuming, you may keep it as is,
> for now. just let me know your position.
> 

This can be changed.

>  - Directory: /nnfs/procs/[pid]/*
> 
> this issue is not serious, but, you will add other control files, right?
> since priority of this part is low, we may skip this part, for now, also.
> 

On Linux the standard process control files appear under /proc.  If
there are others needed for netnice then I missed them.  Could you
specify, which control files are needed that appear under FreeBSD and
that don't have a similar implementation under Linux /proc or
/proc/<pid> ?


>  - Directory: /nnfs/procs/[pid]/*/sockets/
> 
> cann't we cd to the link?
> 
> 	$ cd lo
> 	lo: Not a directory
> 	$
> 
> on FreeBSD system, we can change dir to the link file. if this is Linux's
> specification, that is okay. i just want to know if it is possible, or not.
> 

I did not implement the followlink inode operation, however, I can
attempt to implement this.  I did not think it was necessary as part
of the basic API and you can cd to /nnfs/network/lo.

>  - Directory: /nnfs/network/lo
> 
> i tried parameter setting under lo directory. is this expected behavior?
> i felt it is not, though i also felt it is easy to fix.
> 
>                 $ cat type
>                 Non Work Conserving
> 
>                 $ echo 1 > type; cat type
>                 Block
> 

I will need to investigate this to see what is going on.  On FreeBSD this
should say Weighted Fair Queuing.


>  - Directory: /nnfs/network/lo
> 
>         mkdir of VIF dir:               OK
>         rmdir of VIF dir:               NG?
>                 directory not empty error.
> 

The error message is correct because the vif directory contains
control files that need to be removed first.  The command:

# rm -r vif

should be used to recursively remove it and the control files and it
will. However, even though the vif subdirectory is removed this too
will produce an error message.  The rmdir inode operation is not
implemented due to a non-functioning vif_rm and vif_free.  The
directory is being removed from the filesystem but the underlying vif
is not.  This can be fixed when the internals are working more
completely.

>  - Directory: /nnfs/procs/[pid]/*/sockets/
> 
>         rm of a link to a VIF dir:      OK
>         ln to a VIF dir:                OK
> 
>  - Kernel build
> 
> 	can we merge CONFIG_NNFS and CONFIG_NETNICE?
> 	or, do you think we may leave them, for now?
> 	on FreeBSD, we merged the options.
> 	what do you recommend?
> 

Yes, these can be integrated together where. However, it is good to be able
to specify CONFIG_NNFS as a module instead of a builtin during development
work, that way a reboot is not necessary to make a change.

>  - net/core/vif_subr.c
> 
> 	we completely rewritten vif_rm(). we'll need to fix this,
> 	based on net/vif_suvr.c of FreeBSD5.3.
> 
> thanks!
> 
> 
> -- taka
> 


Thanks,


Scott Brumbaugh

Re: [Netnice-kernels] Linux NNFS API nearing completion

[Takashi O. <ta...@cs...>]

hi scott,

here is my feedback. i checked out the code this afternoon, and used VMware.
it took me quite long to configure the system, since i'm novice at linux.
i updated the wiki based on my experience and put a short note about how
to configure the Linux/Netnice. if you guys have anything to add, or 
anything you want to modify, please feel free to make any change.

overall, i was impressed by the implementation. it is working!
my feedback follows. 

 - Directory: /nnfs/procs/[pid]
               
is it easy to change the directory for the process-dependent files to
the location, /nnfs/[pid]? this is just to keep the comatibility between
implementations. if it is too time consuming, you may keep it as is,
for now. just let me know your position.

 - Directory: /nnfs/procs/[pid]/*

this issue is not serious, but, you will add other control files, right?
since priority of this part is low, we may skip this part, for now, also.

 - Directory: /nnfs/procs/[pid]/*/sockets/

cann't we cd to the link?

	$ cd lo
	lo: Not a directory
	$

on FreeBSD system, we can change dir to the link file. if this is Linux's
specification, that is okay. i just want to know if it is possible, or not.

 - Directory: /nnfs/network/lo

i tried parameter setting under lo directory. is this expected behavior?
i felt it is not, though i also felt it is easy to fix.

                $ cat type
                Non Work Conserving

                $ echo 1 > type; cat type
                Block

 - Directory: /nnfs/network/lo

        mkdir of VIF dir:               OK
        rmdir of VIF dir:               NG?
                directory not empty error.

 - Directory: /nnfs/procs/[pid]/*/sockets/

        rm of a link to a VIF dir:      OK
        ln to a VIF dir:                OK

 - Kernel build

	can we merge CONFIG_NNFS and CONFIG_NETNICE?
	or, do you think we may leave them, for now?
	on FreeBSD, we merged the options.
	what do you recommend?

 - net/core/vif_subr.c

	we completely rewritten vif_rm(). we'll need to fix this,
	based on net/vif_suvr.c of FreeBSD5.3.

thanks!


-- taka

Scott Brumbaugh wrote:
> 
> I have fixed the so_vifnet pointer dereference problem.  The problem
> seems to have been due to uninitialized pointers in the sock_alloc and
> sock_alloc_inode functions in socket.c.  This change is in CVS.
> 
> After fixing this I was able to implement the readdir and lookup
> operations under /nnfs/procs/<pid>/sockets/<fd>.  I have also
> completed the readlink, unlink operations there which are working so
> far.  The symlink operation itself, which will allow the changing of
> pvifs on a socket is still incomplete but should not take very long to
> implement.

[Netnice-kernels] Linux NNFS API nearing completion

[Scott B. <sco...@ve...>]

Hi,

I have fixed the so_vifnet pointer dereference problem.  The problem
seems to have been due to uninitialized pointers in the sock_alloc and
sock_alloc_inode functions in socket.c.  This change is in CVS.

After fixing this I was able to implement the readdir and lookup
operations under /nnfs/procs/<pid>/sockets/<fd>.  I have also
completed the readlink, unlink operations there which are working so
far.  The symlink operation itself, which will allow the changing of
pvifs on a socket is still incomplete but should not take very long to
implement.


Regards,


Scott B

[Netnice-kernels] socket->so_vifnet invalid pointers

[Scott B. <sco...@ve...>]

Hi,

I am running into a problem implementing the nnfs_socketfd_readdir
operation in the /nnfs/procs/<pid>/sockets/<fd>/ directories.  This
operation cooresponds to the FreeBSD function nnfs_readdir with node
id type Pso_dir.

It seems that some of the struct socket objects have so_vifnet
pointers that are not valid.  Dereferencing these pointers lead to
kernel faults.  I am guessing that this is a problem with the
incomplete netnice internals.

In the dump that I have appended notice that the crash occurs when the
address 676f6c2e is dereferenced, this address is probably garbage.

Here is a code snapshot from nnfs_socketfd_readdir:

static int nnfs_socketfd_readdir(struct file * filep, void * dirent,
                                 filldir_t filldir) {

        unsigned int pos = filep->f_pos;
        struct dentry * dentry = filep->f_dentry;
        char *endp;
        int fd = simple_strtol(dentry->d_name.name,&endp,10);
        int pid = (int) dentry->d_inode->u.generic_ip;
        struct task_struct * task;
        struct inode * inode;
        struct socket * socket;
        struct files_struct * files;
        struct file * file;
        struct pvifnet * pvif = 0;
        ino_t ino;

        switch(pos) {
        case 0:
                ino = dentry->d_inode->i_ino;
                if (filldir(dirent,".",1,0,ino,DT_DIR) < 0) {
                        printk("filldir error\n");
                }
                filep->f_pos++;
                return 0;
        case 1:
                ino = parent_ino(dentry);
                if (filldir(dirent,"..",2,1,ino,DT_DIR) < 0) {
                        printk("filldir error\n");
                }
                filep->f_pos++;
                return 0;
        }

        task = find_task_by_pid(pid);
        if (!task) {
                printk("no task for pid %d\n",pid);
                return 0;
        }

        files = get_files_struct(task);
        if (!files) {
                printk("no files for task %d\n",pid);
                return 0;
        }

        spin_lock(&files->file_lock);
        file = fcheck_files(files,fd);
        if (!file) {
                goto out;
        }

        inode = file->f_dentry->d_inode;

        if (!inode || !inode->i_sock || !(socket = SOCKET_I(inode))) {
                goto out;
        }

        pvif = (struct pvifnet *) socket->so_vifnet;
        if (pvif) {
                printk("readdir pid %d fd %d pvif %p state %d sk_state %d\n",
                       pid,fd,pvif,socket->state,socket->sk->sk_state);

                /* crash here due to memory fault */
                printk("found pvifnet %s\n",pvif->dev->name);
        }

 out:
        spin_unlock(&files->file_lock);
        put_files_struct(files);

        return 0;

}

This crash occurs consistently when doing an ls -R /nnfs.  This is a
dump of the kernel log messages:

Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1955 fd 3 pvif f1c846c8 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1955 fd 4 pvif f1c84688 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1956 fd 3 pvif f1c846c8 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1956 fd 4 pvif f1c84688 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1957 fd 3 pvif f1c846c8 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1957 fd 4 pvif f1c84688 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1958 fd 3 pvif f1c846c8 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1958 fd 4 pvif f1c84688 state 1 sk_state 10
Oct 21 13:25:43 tamarack kernel: found pvifnet eth0
Oct 21 13:25:43 tamarack kernel: readdir pid 1959 fd 4 pvif 676f6c2e state 3 sk_state 1
Oct 21 13:25:43 tamarack kernel: Unable to handle kernel paging request at virtual address 676f6c32
Oct 21 13:25:43 tamarack kernel:  printing eip:
Oct 21 13:25:43 tamarack kernel: f8977b67
Oct 21 13:25:43 tamarack kernel: *pde = 00000000
Oct 21 13:25:43 tamarack kernel: Oops: 0000 [#1]
Oct 21 13:25:43 tamarack kernel: PREEMPT SMP
Oct 21 13:25:43 tamarack kernel: Modules linked in: nnfs
Oct 21 13:25:43 tamarack kernel: CPU:    0
Oct 21 13:25:43 tamarack kernel: EIP:    0060:[<f8977b67>]    Not tainted
Oct 21 13:25:43 tamarack kernel: EFLAGS: 00010286   (2.6.7-nnice)
Oct 21 13:25:43 tamarack kernel: EIP is at nnfs_socketfd_readdir+0xfa/0x23d [nnfs]
Oct 21 13:25:43 tamarack kernel: eax: 00000037   ebx: f7bc7b80   ecx: c04320b4   edx: 00000286
Oct 21 13:25:43 tamarack kernel: esi: 00000002   edi: 676f6c2e   ebp: eb7b3080   esp: e9c39f38
Oct 21 13:25:43 tamarack kernel: ds: 007b   es: 007b   ss: 0068
Oct 21 13:25:43 tamarack kernel: Process ls (pid: 3768, threadinfo=e9c39000 task=ef247290)

Re: [Netnice-kernels] NNFS symlinks for VIF process attachment

[Takashi O. <ta...@wi...>]

hi scott,

i got really impressed by the session. it's functioning!!

you may use the page below for the progress report to the public.

	http://www.netnice.org/pukiwiki.php?Linux

"ln" syntax won't be a problem, since users use commands, like netnice,
not the direct operations. also, we'll wrap the syscall soon by an
os-independent library, libnetnice.

anyways. thanks for your help. it looks really great...


-- taka

Scott Brumbaugh wrote:
> 
> Hi Takashi,
> 
> I am moving along in the development and am at a point where much of
> the API is in place.  It is not done but it is getting there. At some
> point we will need to agree that the API work is complete as it can be
> given the missing internals.
> 
> I have implemented the symlink operation for attaching a VIF to a
> process.  The syntax is different from FreeBSD.  Under FreeBSD a command
> like:
> 
>   # ln -s /nnfs/network/lo0/vif1
> 
> will create a symlink under <pid>/sockets called lo0 that points to
> vif1.  According to the man page for ln, this command should create a
> symlink called vif1.
> 
> Under Linux NNFS this command will return an error because vif1 is not
> the name of a network interface.  The command on Linux to attach a vif
> to a process is:
> 
>   # ln -sf /nnfs/network/lo/vif1 lo
> 
> This command says force the creation of the symlink named lo. The -f
> switch is needed because a symlink named lo already exists. If you don't
> want to use the -f switch you must first remove the symlink before creating
> a new one like this:
> 
>   # rm lo
>   # ln -s /nnfs/netword/lo/vif1 lo
> 
> Here is a sample session of the features that are in place and have been
> commited to your CVS:
> 
> [root@tamarack root]# uname -a
> Linux tamarack.inyotech.local 2.6.7-nnice #9 SMP Wed Oct 20 09:12:36 PDT 2004 i686 i686 i386 GNU/Linux
> [root@tamarack root]# /sbin/modprobe nnfs
> [root@tamarack root]# mount -t nnfs none /nnfs
> [root@tamarack root]# ls /nnfs/network/
> eth0  lo
> [root@tamarack root]# mkdir /nnfs/network/eth0/vif1
> [root@tamarack root]# ls -l /nnfs/network/eth0/vif1/
> total 0
> -rw-r--r--  1 root root 0 Oct 20 11:26 bandwidth
> -rw-r--r--  1 root root 0 Oct 20 11:26 drops
> -rw-r--r--  1 root root 0 Oct 20 11:26 filter
> -rw-r--r--  1 root root 0 Oct 20 11:26 port
> -rw-r--r--  1 root root 0 Oct 20 11:26 recv
> -rw-r--r--  1 root root 0 Oct 20 11:26 send
> -rw-r--r--  1 root root 0 Oct 20 11:26 type
> -rw-r--r--  1 root root 0 Oct 20 11:26 weight
> [root@tamarack root]# cat /nnfs/network/eth0/vif1/bandwidth
>      0
> [root@tamarack root]# echo 128K > /nnfs/network/eth0/vif1/bandwidth
> [root@tamarack root]# cat /nnfs/network/eth0/vif1/bandwidth
> 136000
> [root@tamarack root]# ps ax | grep sendmail
>  1852 ?        S      0:00 sendmail: accepting connections
>  1863 ?        S      0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
>  2479 pts/1    S      0:00 grep sendmail
> [root@tamarack root]# cd /nnfs/procs/1852/sockets/
> [root@tamarack sockets]# ls -l
> total 0
> drwxr-xr-x  3 root root 0 Oct 20 11:28 3
> drwxr-xr-x  3 root root 0 Oct 20 11:28 4
> lrwxr-xr-x  1 root root 0 Oct 20 11:28 eth0 -> /nnfs/network/eth0
> lrwxr-xr-x  1 root root 0 Oct 20 11:28 lo -> /nnfs/network/lo
> [root@tamarack sockets]# ln -sf /nnfs/network/eth0/vif1 eth0
> [root@tamarack sockets]# ls -l
> total 0
> drwxr-xr-x  3 root root 0 Oct 20 11:28 3
> drwxr-xr-x  3 root root 0 Oct 20 11:28 4
> lrwxr-xr-x  1 root root 0 Oct 20 11:28 eth0 -> /nnfs/network/eth0/vif1
> lrwxr-xr-x  1 root root 0 Oct 20 11:28 lo -> /nnfs/network/lo
> [root@tamarack sockets]#
> 
> Thanks,
> 
> Scott Brumbaugh
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Netnice-kernels mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netnice-kernels

[Netnice-kernels] NNFS symlinks for VIF process attachment

[Scott B. <sco...@ve...>]

Hi Takashi,

I am moving along in the development and am at a point where much of
the API is in place.  It is not done but it is getting there. At some
point we will need to agree that the API work is complete as it can be
given the missing internals.

I have implemented the symlink operation for attaching a VIF to a
process.  The syntax is different from FreeBSD.  Under FreeBSD a command
like:

  # ln -s /nnfs/network/lo0/vif1

will create a symlink under <pid>/sockets called lo0 that points to
vif1.  According to the man page for ln, this command should create a
symlink called vif1.

Under Linux NNFS this command will return an error because vif1 is not
the name of a network interface.  The command on Linux to attach a vif
to a process is:

  # ln -sf /nnfs/network/lo/vif1 lo

This command says force the creation of the symlink named lo. The -f
switch is needed because a symlink named lo already exists. If you don't
want to use the -f switch you must first remove the symlink before creating
a new one like this:

  # rm lo
  # ln -s /nnfs/netword/lo/vif1 lo

Here is a sample session of the features that are in place and have been
commited to your CVS:

[root@tamarack root]# uname -a
Linux tamarack.inyotech.local 2.6.7-nnice #9 SMP Wed Oct 20 09:12:36 PDT 2004 i686 i686 i386 GNU/Linux
[root@tamarack root]# /sbin/modprobe nnfs
[root@tamarack root]# mount -t nnfs none /nnfs
[root@tamarack root]# ls /nnfs/network/
eth0  lo
[root@tamarack root]# mkdir /nnfs/network/eth0/vif1
[root@tamarack root]# ls -l /nnfs/network/eth0/vif1/
total 0
-rw-r--r--  1 root root 0 Oct 20 11:26 bandwidth
-rw-r--r--  1 root root 0 Oct 20 11:26 drops
-rw-r--r--  1 root root 0 Oct 20 11:26 filter
-rw-r--r--  1 root root 0 Oct 20 11:26 port
-rw-r--r--  1 root root 0 Oct 20 11:26 recv
-rw-r--r--  1 root root 0 Oct 20 11:26 send
-rw-r--r--  1 root root 0 Oct 20 11:26 type
-rw-r--r--  1 root root 0 Oct 20 11:26 weight
[root@tamarack root]# cat /nnfs/network/eth0/vif1/bandwidth
     0
[root@tamarack root]# echo 128K > /nnfs/network/eth0/vif1/bandwidth
[root@tamarack root]# cat /nnfs/network/eth0/vif1/bandwidth
136000
[root@tamarack root]# ps ax | grep sendmail
 1852 ?        S      0:00 sendmail: accepting connections
 1863 ?        S      0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
 2479 pts/1    S      0:00 grep sendmail
[root@tamarack root]# cd /nnfs/procs/1852/sockets/
[root@tamarack sockets]# ls -l
total 0
drwxr-xr-x  3 root root 0 Oct 20 11:28 3
drwxr-xr-x  3 root root 0 Oct 20 11:28 4
lrwxr-xr-x  1 root root 0 Oct 20 11:28 eth0 -> /nnfs/network/eth0
lrwxr-xr-x  1 root root 0 Oct 20 11:28 lo -> /nnfs/network/lo
[root@tamarack sockets]# ln -sf /nnfs/network/eth0/vif1 eth0
[root@tamarack sockets]# ls -l
total 0
drwxr-xr-x  3 root root 0 Oct 20 11:28 3
drwxr-xr-x  3 root root 0 Oct 20 11:28 4
lrwxr-xr-x  1 root root 0 Oct 20 11:28 eth0 -> /nnfs/network/eth0/vif1
lrwxr-xr-x  1 root root 0 Oct 20 11:28 lo -> /nnfs/network/lo
[root@tamarack sockets]# 


Thanks,


Scott Brumbaugh

Re: [Netnice-kernels] procs/<pid>/sockets submission

[Scott B. <sco...@ve...>]

Hi,

I am back working on NNFS.  Today I ported some functions from
nnfs_subr.c to Linux, vifinet2path, path2ifnet, path2vifnet.  These
are needed in for creating the symlinks under the Pso_list directory.
I have not yet ported remove_vif.  There are differences between Linux
and FreeBSD filesystems regarding directory entry caching that I have
not completely figured out yet.

I have begun implementing the symlink operation in the Pso_list
directory.  This is more complicated than other operations that I have
done so far.  I have not completed this yet, I might have this done by
the end of tomorrow.


Thanks,

Scott Brumbaugh

RE: [Netnice-kernels] procs/<pid>/sockets submission

[Scott B. <sco...@ve...>]

Hi,

I have ported the file nnfs_fileno.c to linux and have modified NNFS
to use the FILENO_* functions to allocate inode numbers.  I have done
more work on the nnfs_socket_readdir and have implemented
nnfs_socket_lookup.

Now you can do an ls in the /nnfs/procs/<pid>/sockets directory and
see all open socket file descriptors and vif interfaces.  I have not
yet implemented the symlink operations so the vif interfaces show up
as regular files.

I have submitted these changes to CVS.  Again, I am traveling out of
town and will be back to work on NNFS Tuesday morning.



Regards,

Scott B

RE: [Netnice-kernels] procs/<pid>/sockets submission

[Scott B. <sco...@ve...>]

Hi Kartikey,

I replied to you last night, I will reply the same here to the
mailing-list.

On Thu, 14 Oct 2004, kartikey bhatt wrote:

> hi,
> 
> when nnfs is mounted only specific subdirectories for
> pid are created in procs procs dir rather than for all
> the processes in the system. moreover when the new
> process is created no directory is created for that process
> too.
> 

You are correct.  Those are problems with the earlier snapshot patch I
gave you.  Those particular problems should have been fixed by the
latest CVS submissions.

> the kernel works and boots with fork.c and ip_output.c changes
> as made by me. the lo interface is also registered successfully.
> however when an nic driver is built in or linked as a module
> it crashes.
> 

I am building my kernels with the sk98lin ethernet driver built in,
not as a module and the kernel is running well.  I found that the
vif_rm function was causing a crash soon after boot and disabled it.

> regards,
> 
> --kartikey
> 


Thanks,

Scott B

RE: [Netnice-kernels] procs/<pid>/sockets submission

[kartikey b. <kar...@ho...>]

hi,

when nnfs is mounted only specific subdirectories for
pid are created in procs procs dir rather than for all
the processes in the system. moreover when the new
process is created no directory is created for that process
too.

the kernel works and boots with fork.c and ip_output.c changes
as made by me. the lo interface is also registered successfully.
however when an nic driver is built in or linked as a module
it crashes.

regards,

--kartikey

>From: Scott Brumbaugh <sco...@ve...>
>To: Takashi Okumura <ta...@cs...>
>CC: net...@li...
>Subject: [Netnice-kernels] procs/<pid>/sockets submission
>Date: Wed, 13 Oct 2004 15:51:27 -0700 (PDT)
>
>Hi,
>
>I have submitted some more changes to the netnice267 branch.  These
>changes cleanup the nnfs_netnice.c file and add the beginnings of the
>symlinks under the sockets directory.
>
>It took me a while to figure out how to determine if a file descriptor
>that a process has open is a socket vs a regular file.  I eventually
>came up with an implementation in the function nnfs_socket_readdir.
>There will be more work on this function tomorrow but the skeleton is
>working.  It traverses all the p_vifnet structures and socket file
>descriptors for a process and will update /nnfs/procs/<pid>/sockets.
>
>
>Scott B
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Netnice-kernels mailing list
>Net...@li...
>https://lists.sourceforge.net/lists/listinfo/netnice-kernels

_________________________________________________________________
Seized by wanderlust? Have the best vacation ever. 
http://www.msn.co.in/Travel/ Team up with MSN Travel!

[Netnice-kernels] procs/<pid>/sockets submission

[Scott B. <sco...@ve...>]

Hi,

I have submitted some more changes to the netnice267 branch.  These
changes cleanup the nnfs_netnice.c file and add the beginnings of the
symlinks under the sockets directory.

It took me a while to figure out how to determine if a file descriptor
that a process has open is a socket vs a regular file.  I eventually
came up with an implementation in the function nnfs_socket_readdir.
There will be more work on this function tomorrow but the skeleton is
working.  It traverses all the p_vifnet structures and socket file
descriptors for a process and will update /nnfs/procs/<pid>/sockets.


Scott B

Re: [Netnice-kernels] VIF control files

[Takashi O. <ta...@cs...>]

hi,


Scott Brumbaugh wrote:
> 
> I have commited changes that implement the read and write file
> operations on the control files, these are bandwidth, weight, etc... I
> used the files nnfs_netnice.c and nnfs.h from the FreeBSD5 version.
> There is a lot of cleanup left, but the operations do work.  I have
> not implemented read or write on the filter control file.  I dont'
> know if that is ready in the internals.

thanks for the update. i don't think filter/port mechanism is properly
ported onto linux. just leave them for now.

thanks!


-- taka

[Netnice-kernels] VIF control files

[Scott B. <sco...@ve...>]

Hi,

I have commited changes that implement the read and write file
operations on the control files, these are bandwidth, weight, etc... I
used the files nnfs_netnice.c and nnfs.h from the FreeBSD5 version.
There is a lot of cleanup left, but the operations do work.  I have
not implemented read or write on the filter control file.  I dont'
know if that is ready in the internals.

I will probably do some clean-up tomorrow.

Scott B

Re: [Netnice-kernels] Linux Kernel

[kartikey b. <kar...@ho...>]

Hi Scott,

I would appreciate if you generate a separate patch
of the integration of my code and your code against
2.6.7 and send it to me as bzipped file. Cuz i don't
have broadband connection at home.

--kartikey

>From: Scott Brumbaugh <sco...@ve...>
>To: kartikey bhatt <kar...@ho...>
>CC: net...@li...
>Subject: Re: [Netnice-kernels] Linux Kernel
>Date: Fri, 8 Oct 2004 15:32:18 -0700 (PDT)
>
>On Sat, 9 Oct 2004, kartikey bhatt wrote:
>
> > Hi Scott,
> > What do you think about the status?
> > Would you send me the changes that
> > you have made?
> >
> > Regards,
> > --kartikey
> >
>
>Hi Kartikey,
>
>The kernel is working ok after I disabled vif_fork and the ip_output
>routines.  I simply changed CONFIG_NETNICE to CONFIG_NETNICE_X, there
>is a diff appended to this note for your info.  I have submitted your
>patch and the start of the NNFS api to the netnice267 branch.  You can
>get it by doing:
>
>  $ cvs co -r netnice267 Linux
>
>
>Regards,
>
>Scott B
>
>
>
>diff --exclude=CVS -aur linux-org/kernel/fork.c Linux.latest/kernel/fork.c
>--- linux-org/kernel/fork.c	2004-10-08 14:56:32.117452113 -0700
>+++ Linux.latest/kernel/fork.c	2004-10-08 13:56:18.000000000 -0700
>@@ -1232,7 +1232,7 @@
>
>  			put_cpu();
>  		}
>-#ifdef CONFIG_NETNICE
>+#ifdef CONFIG_NETNICE_X
>  		//printk (KERN_CRIT "Calling vif_fork\n");
>  		vif_fork (current, p);
>  #endif
>diff --exclude=CVS -aur linux-org/Makefile Linux.latest/Makefile
>--- linux-org/Makefile	2004-06-15 22:19:37.000000000 -0700
>+++ Linux.latest/Makefile	2004-10-08 13:56:18.000000000 -0700
>@@ -1,7 +1,7 @@
>  VERSION = 2
>  PATCHLEVEL = 6
>  SUBLEVEL = 7
>-EXTRAVERSION =
>+EXTRAVERSION = -nnice
>  NAME=Zonked Quokka
>
>  # *DOCUMENTATION*
>Only in linux-org/net/core: output
>diff --exclude=CVS -aur linux-org/net/core/vif_subr.c 
>Linux.latest/net/core/vif_subr.c
>--- linux-org/net/core/vif_subr.c	2004-10-08 14:56:32.122450682 -0700
>+++ Linux.latest/net/core/vif_subr.c	2004-10-08 14:35:20.000000000 -0700
>@@ -84,6 +84,8 @@
>  {
>  	struct vifnet *vif;
>
>+	printk("register_vif %s\n",dev->name);
>+
>  	/* range check */
>  	if (!dev || dev->ifindex >= MAX_INTERFACE)
>  		return;
>@@ -660,6 +662,8 @@
>  	printk (KERN_INFO "Netnice for linux initialized");
>  }
>
>+EXPORT_SYMBOL(vif_alloc);
>+EXPORT_SYMBOL(vifnet);
>  EXPORT_SYMBOL(vif_fork);
>  EXPORT_SYMBOL(vif_exit);
>  EXPORT_SYMBOL(vif_init);
>diff --exclude=CVS -aur linux-org/net/ipv4/ip_output.c 
>Linux.latest/net/ipv4/ip_output.c
>--- linux-org/net/ipv4/ip_output.c	2004-10-08 14:56:32.124450110 -0700
>+++ Linux.latest/net/ipv4/ip_output.c	2004-10-08 13:56:38.000000000 -0700
>@@ -224,7 +224,7 @@
>
>  	skb->dev = dev;
>
>-#ifdef CONFIG_NETNICE
>+#ifdef CONFIG_NETNICE_X
>  	skb->skb_pvif = so->so_vifnet;
>  	skb->protocol = htons(ETH_P_IP);
>  	return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev,
>@@ -1331,7 +1331,7 @@
>
>  static struct packet_type ip_packet_type = {
>  	.type = __constant_htons(ETH_P_IP),
>-#ifdef CONFIG_NETNICE
>+#ifdef CONFIG_NETNICE_X
>  	.func = vif_rcv,
>  #else
>  	.func = ip_rcv,
>

_________________________________________________________________
Cool ringtones, snazzy logos! Expressive cards, fun games! 
http://www.msn.co.in/Mobile/ Get it all at MSN mobile!

Re: [Netnice-kernels] Re: Integration of Kertikey's code and Scott's code

[Scott B. <sco...@ve...>]

Hi,

I merged all the code into the netnice267 branch.  It compiles and
runs here although the netnice internals are not operational.  To
build it checkout netnice267 and do make xconfig.  Select
drivers>Networking>Options>Netnice for the internals.  Select File
systems>Pseudo>Netnice for NNFS.  There are some compiler warnings.
Boot the kernel and as root do:

  # mkdir /nnfs
  # mount -t nnfs none /nnfs

The root vifs appear under /nnfs/network and the sockets directories
appear under /nnfs/procs/<pid>.

This week I have been mostly working on getting the kernel to run with
all the various patches so I have not been concentrating on the API.
I am going to back my completion estimate up by 1 week.  I think I
will have the NNFS in place at the end of the first week in November.


Regards,

Scott B

Re: [Netnice-kernels] Linux Kernel

[Scott B. <sco...@ve...>]

On Sat, 9 Oct 2004, kartikey bhatt wrote:

> Hi Scott,
> What do you think about the status?
> Would you send me the changes that
> you have made?
> 
> Regards,
> --kartikey
> 

Hi Kartikey,

The kernel is working ok after I disabled vif_fork and the ip_output
routines.  I simply changed CONFIG_NETNICE to CONFIG_NETNICE_X, there
is a diff appended to this note for your info.  I have submitted your
patch and the start of the NNFS api to the netnice267 branch.  You can
get it by doing:

 $ cvs co -r netnice267 Linux


Regards,

Scott B



diff --exclude=CVS -aur linux-org/kernel/fork.c Linux.latest/kernel/fork.c
--- linux-org/kernel/fork.c	2004-10-08 14:56:32.117452113 -0700
+++ Linux.latest/kernel/fork.c	2004-10-08 13:56:18.000000000 -0700
@@ -1232,7 +1232,7 @@
 
 			put_cpu();
 		}
-#ifdef CONFIG_NETNICE
+#ifdef CONFIG_NETNICE_X
 		//printk (KERN_CRIT "Calling vif_fork\n");
 		vif_fork (current, p);
 #endif
diff --exclude=CVS -aur linux-org/Makefile Linux.latest/Makefile
--- linux-org/Makefile	2004-06-15 22:19:37.000000000 -0700
+++ Linux.latest/Makefile	2004-10-08 13:56:18.000000000 -0700
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 7
-EXTRAVERSION =
+EXTRAVERSION = -nnice
 NAME=Zonked Quokka
 
 # *DOCUMENTATION*
Only in linux-org/net/core: output
diff --exclude=CVS -aur linux-org/net/core/vif_subr.c Linux.latest/net/core/vif_subr.c
--- linux-org/net/core/vif_subr.c	2004-10-08 14:56:32.122450682 -0700
+++ Linux.latest/net/core/vif_subr.c	2004-10-08 14:35:20.000000000 -0700
@@ -84,6 +84,8 @@
 {
 	struct vifnet *vif;
 
+	printk("register_vif %s\n",dev->name);
+
 	/* range check */
 	if (!dev || dev->ifindex >= MAX_INTERFACE)
 		return;
@@ -660,6 +662,8 @@
 	printk (KERN_INFO "Netnice for linux initialized");
 }
 
+EXPORT_SYMBOL(vif_alloc);
+EXPORT_SYMBOL(vifnet);
 EXPORT_SYMBOL(vif_fork);
 EXPORT_SYMBOL(vif_exit);
 EXPORT_SYMBOL(vif_init);
diff --exclude=CVS -aur linux-org/net/ipv4/ip_output.c Linux.latest/net/ipv4/ip_output.c
--- linux-org/net/ipv4/ip_output.c	2004-10-08 14:56:32.124450110 -0700
+++ Linux.latest/net/ipv4/ip_output.c	2004-10-08 13:56:38.000000000 -0700
@@ -224,7 +224,7 @@
 
 	skb->dev = dev;
 
-#ifdef CONFIG_NETNICE
+#ifdef CONFIG_NETNICE_X
 	skb->skb_pvif = so->so_vifnet;
 	skb->protocol = htons(ETH_P_IP);
 	return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev,
@@ -1331,7 +1331,7 @@
 
 static struct packet_type ip_packet_type = {
 	.type = __constant_htons(ETH_P_IP),
-#ifdef CONFIG_NETNICE
+#ifdef CONFIG_NETNICE_X
 	.func = vif_rcv,
 #else
 	.func = ip_rcv,

Re: [Netnice-kernels] Re: Integration of Kertikey's code and Scott's code

[Takashi O. <ta...@cs...>]

alright. now, we'll have an unified linux code, soon. thanks scott. and,
i'm sorry if there was any misunderstanding, or anything unclear at my side.

thanks!

-- taka

Scott Brumbaugh wrote:
> 
> Hi,
> 
> I will apply kartikey's latest changes to the netnice267 branch.  His
> kernel seems to be working as I am using it to do this work.
> 
> Scott B

[Netnice-kernels] Re: Integration of Kertikey's code and Scott's code

[Scott B. <sco...@ve...>]

On Fri, 8 Oct 2004, Takashi Okumura wrote:

> Scott Brumbaugh wrote:
> > I am thinking that I should add this to your CVS on a new branch off
> > of MAIN, maybe called kartikey and then merge the fs/nnfs directory
> > from the netnice267 branch.
> 
> i don't get scott's point here, why we need to set up a new branch for
> the integrated code, which may make the CVS a bit more complicated.
> isn't it possible to merge his code into your latest local copy, and
> commit it to the repository? that way everybody can simply update
> things... it is totally okay with me as long as you give us reasonable
> explanation. but, at this point, i'm a bit confused.
> 
> since you have a developer access to the repository, you can create the
> new branch you mentioned, but, i would be happy if you convince us first.
> 
> thanks!
> 
> -- taka
> 

Hi,

I will apply kartikey's latest changes to the netnice267 branch.  His
kernel seems to be working as I am using it to do this work.  


Scott B

[Netnice-kernels] Integration of Kertikey's code and Scott's code

[Takashi O. <ta...@cs...>]

alright. thanks kartikey.

i've got the file, and applied to linux-2.6.7.

>% bzip2 -dc ~/netnice-linux.diff.bz2 | patch -p1 --dry-run
> (snip)
> patching file kernel/exit.c
> Hunk #1 FAILED at 805.
> 1 out of 1 hunk FAILED -- saving rejects to file kernel/exit.c.rej
> (snip)
> patching file net/Kconfig
> The next patch would delete the file scripts/mod/elfconfig.h,
> which does not exist!  Assume -R? [n]
> Apply anyway? [n] y
> can't find file to patch at input line 2619
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |diff -Nru linux/scripts/mod/elfconfig.h linux-patched/scripts/mod/elfconfig.h
> |--- linux/scripts/mod/elfconfig.h      2004-09-25 23:49:46.000000000 +1000
> |+++ linux-patched/scripts/mod/elfconfig.h      1970-01-01 10:00:00.000000000 +1000
> --------------------------
> File to patch: y
> y: No such file or directory
> Skip this patch? [y]
> Skipping patch.
> 1 out of 1 hunk ignored
> nitrogen{19} pwd
> /tmp/linux-2.6.7

so, it looks mostly okay. as Scott suggested, it would work after minor
changes.

i appreciate your help, and now we have the latest codes, kartikey's
core-module, and scott's NNFS API (netnice file system, which is a subset
of linux procfs + netnice API extension). and so, as you guys mentioned,
we need to decide how to integrate the things together...

Kartikey bhatt wrote:
>
> What do you think about the status?
> Would you send me the changes that you have made?

Scott Brumbaugh wrote:
> I am thinking that I should add this to your CVS on a new branch off
> of MAIN, maybe called kartikey and then merge the fs/nnfs directory
> from the netnice267 branch.

i don't get scott's point here, why we need to set up a new branch for
the integrated code, which may make the CVS a bit more complicated.
isn't it possible to merge his code into your latest local copy, and
commit it to the repository? that way everybody can simply update
things... it is totally okay with me as long as you give us reasonable
explanation. but, at this point, i'm a bit confused.

since you have a developer access to the repository, you can create the
new branch you mentioned, but, i would be happy if you convince us first.

thanks!

-- taka

p.s.

for further discussion of the issue, please reply to this email.
i have renamed the subject to match the topic. thx.


Scott Brumbaugh wrote:
> 
> Hi Kartikey,
> 
> Thanks for the new patch, I have applied it and am running it now.
> I did have to disable vif_fork and the changes in ip_output.c in
> order to run the kernel here, I also needed to manually update
> kernel/exit.c.
> 
> Regards
> 
> Scott B

Re: [Netnice-kernels] Linux Kernel

[kartikey b. <kar...@ho...>]

i dont know which mailing address do you have?
but it is:
Kartikey M Bhatt
3-5 Watson Esplanade,
Surfers Paradise - 4217
Queensland.
Australia.

Anyways sending the file again.
dont know what is the problem.

Regards,
--kartikey

>From: Takashi Okumura <ta...@cs...>
>To: kartikey bhatt <kar...@ho...>
>CC: sco...@ve...,net...@li...
>Subject: Re: [Netnice-kernels] Linux Kernel
>Date: Fri, 08 Oct 2004 12:17:07 -0400
>
>thanks kartikey,
>
>and it's good to know that you feel okay now.
>
>but, where's the file...? i think it is not attached.
>
>
>-- taka
>
>p.s.
>
>i have to apologize to you. today, i realized that a guy i asked to
>send you the additional supplies did not send them to you. i'm
>asking him to ship everything asap. so, if you have changed your
>mailing address, please let me know. sorry...
>
>
>kartikey bhatt wrote:
> >
> > hi taka,
> >
> > i am feeling alright now. thanks.
> > i dont know what is the problem with
> > online cvs repository. but here i have
> > regenerated the patch using typical -urN
> > option, bzipped it and sending it again.
> > to apply just go to the fresh 2.6.7 directory
> > and issue comman bzip2 -dc netnice-linux.diff.bz2 | patch -p1 --dry-run.
> >
> > regards,
> > kartikey
>

_________________________________________________________________
Get answers to life’s queries. 
http://www.astroyogi.com/newmsn/astroshopping/astrologerservices/astrotalk.asp 
At your own time and leisure.

Re: [Netnice-kernels] Linux Kernel

[kartikey b. <kar...@ho...>]

Hi Scott,
What do you think about the status?
Would you send me the changes that
you have made?

Regards,
--kartikey

>From: Scott Brumbaugh <sco...@ve...>
>To: kartikey bhatt <kar...@ho...>
>CC: Takashi Okumura <ta...@cs...>,      
><net...@li...>
>Subject: Re: [Netnice-kernels] Linux Kernel
>Date: Fri, 8 Oct 2004 11:37:43 -0700 (PDT)
>
>Hi Kartikey,
>
>Thanks for the new patch, I have applied it and am running it now.
>I did have to disable vif_fork and the changes in ip_output.c in
>order to run the kernel here, I also needed to manually update
>kernel/exit.c.
>
>Regards
>
>
>Scott B
>

_________________________________________________________________
Seized by wanderlust? Have the best vacation ever. 
http://www.msn.co.in/Travel/ Team up with MSN Travel!