AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071109180233.17023714@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<maxim.kozlovsky@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E06882CCA@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 9 Nov 2007 18:02:44 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
Subject: Re: Please review
Message-ID: <20071109180244.6aaa36cf@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E06882CCA@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E06882B8A@onstor-exch02.onstor.net>
	<20071109163628.1efdb0bd@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E06882C85@onstor-exch02.onstor.net>
	<20071109163913.1dfd6e2d@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E06882C8C@onstor-exch02.onstor.net>
	<20071109170631.76a42772@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E06882CCA@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 9 Nov 2007 17:10:05 -0800 "Maxim Kozlovsky"
<maxim.kozlovsky@onstor.com> wrote:

> It is ugly and it will not work for bmfpga accesses. 

It's the most beautiful code ever, especially compared to yours.  It's
so beautiful, it doesn't even matter if it doesn't work.  That's just
how beautiful it is.

Nevertheless, I have included a review below.  A /proc driver would be
so much better....

> >-----Original Message-----
> >From: Andy Sharp
> >Sent: Friday, November 09, 2007 5:07 PM
> >To: Maxim Kozlovsky
> >Cc: Tim Gardner
> >Subject: Re: Please review
> >
> >You didn't expect me to pay attention, did you?
> >
> >This should be all that is needed to make the current user code work
> >unmodified:
> >
> >diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> >index 1d58db4..d160b37 100644
> >--- a/drivers/char/mem.c
> >+++ b/drivers/char/mem.c
> >@@ -555,7 +555,14 @@ static ssize_t write_kmem(struct file * file,
> const
> >char __
> > static ssize_t read_port(struct file * file, char __user * buf,
> >                         size_t count, loff_t *ppos)
> > {
> >+       /*
> >+        * on MIPS64, virtual addresses in kseg0/1 must be sign
> extended
> >+        */
> >+#ifdef CONFIG_64BIT
> >+       long long p = *ppos;
> >+#else
> >        unsigned long p = *ppos;
> >+#endif
> >        ssize_t read, sz;
> >        char * kbuf; /* k-addr because vread() takes vmlist_lock
> > rwlock
> */
> >
> >@@ -595,7 +602,7 @@ static ssize_t read_port(struct file * file, char
> >__user * b
> >         if (copy_to_user(buf, kbuf, sz))
> >             return -EFAULT;
> >         buf += sz;
> >-        p += sz;
> >+        p = (unsigned)p + sz;
> >         read += sz;
> >         count -= sz;
> >     }
> >@@ -607,9 +614,13 @@ static ssize_t read_port(struct file * file,
> >char __user *
> > static ssize_t write_port(struct file * file, const char __user *
> > buf, size_t count, loff_t *ppos)
> > {
> >+#ifdef CONFIG_64BIT
> >+       long long p = *ppos;
> >+#else
> >        unsigned long p = *ppos;
> >+#endif
> >
> >-    if ((*ppos >> 28) != 0xb) {
> >+    if (((*ppos >> 28) & 0xf) != 0xb) {
> >         return -EINVAL;
> >     }
> >
> >
> >On Fri, 9 Nov 2007 16:40:05 -0800 "Maxim Kozlovsky"
> ><maxim.kozlovsky@onstor.com> wrote:
> >
> >> This does not work. Where have you been while I explained about
> >> negative offsets?
> >>
> >> >-----Original Message-----
> >> >From: Andy Sharp
> >> >Sent: Friday, November 09, 2007 4:39 PM
> >> >To: Maxim Kozlovsky
> >> >Subject: Re: Please review
> >> >
> >> >Checked in many moons ago, look for ifdef CONFIG_MIPS for
> read_port()
> >> >and write_port().
> >> >
> >> >On Fri, 9 Nov 2007 16:38:13 -0800 "Maxim Kozlovsky"
> >> ><maxim.kozlovsky@onstor.com> wrote:
> >> >
> >> >> Where are the modifications? I don't see anything checked in.
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Andy Sharp
> >> >> >Sent: Friday, November 09, 2007 4:36 PM
> >> >> >To: Maxim Kozlovsky
> >> >> >Subject: Re: Please review
> >> >> >
> >> >> >None of this should be necessary.  Especially the bsd related
> >> >> >changes. Linux uses /dev/port which has already been modified
> >> >> >and should work fine without any further mods.
> >> >> >
> >> >> >On Fri, 9 Nov 2007 14:42:39 -0800 "Maxim Kozlovsky"
> >> >> ><maxim.kozlovsky@onstor.com> wrote:
> >> >> >
> >> >> >> Change 26287 by maximk@maximk-13 on 2007/11/09 14:34:58
> >> >> >> *pending*
> >> >> >>
> >> >> >>         Add a device allowing the user processes to whack at
> >> >> >> physical memory
> >> >> >>            whenever they want.
> >> >> >>
> >> >> >>            Change the bmfpga and galileo / sibyte register
> >> accesses
> >> >> >> from chassisd to use plain physical addresses instead of
> >> >> >> KSEG1 addresses.
> >> >> >>
> >> >> >>            Set the offset to access the physical memory to
> >> >> >> 0xa0000000 for BSD
> >> >> >>            resulting in old behavior where the KSEG1 is
> accesses
> >> >> >> and to 0 for
> >> >> >>            Linux, which uses the new device on bobcat and
> >> >> >> cougar.
> >> >> >>
> >> >> >>            Reviewed by andys.
> >> >> >>
> >> >> >> Affected files ...
> >> >> >>
> >> >> >> ...
> //depot/dev/linux/kernel/linux-mips-2.6/drivers/char/mem.c#2
> >> >> >> edit ... //depot/dev/nfx-tree/code/sm-chassis/chassis-ui.c#6
> >> >> >> edit ... //depot/dev/nfx-tree/code/sm-chassis/chassisd-bc.c#5
> >> >> >> edit ... //depot/dev/nfx-tree/code/sm-chassis/cm-api-bc.h#3
> edit
> >> >> >> ... //depot/dev/nfx-tree/code/sm-chassis/linux.h#1 edit
> >> >> >> ... //depot/dev/nfx-tree/code/sm-chassis/openbsd.h#1 edit
> >> >> >> ... //depot/dev/nfx-tree/code/ssc-genlib/cm-util-bc.c#3 edit
> >> >> >> ... //depot/dev/nfx-tree/code/ssc-genlib/linux.h#1 edit
> >> >> >> ... //depot/dev/nfx-tree/code/ssc-genlib/openbsd.h#1 edit
> >> >> >>

Is this tested on something-linux?  I'm wondering if udev is creating
the device node for us like a good little boy, or if we have to add it
to the rootfs/udev stuff.

linux/kernel/linux-mips-2.6/drivers/char/mem.c

     line 995, don't say sibyte

nfx-tree/code/sm-chassis/chassis-ui.c

     looks good

nfx-tree/code/sm-chassis/chassisd-bc.c

     line 1133 you're not unlocking the i2c lock anymore...

nfx-tree/code/sm-chassis/cm-api-bc.h

     looks good

nfx-tree/code/sm-chassis/linux.h

     looks good

nfx-tree/code/sm-chassis/openbsd.h

     looks good

nfx-tree/code/ssc-genlib/cm-util-bc.c

     line 88, this looks broken to me.  we're poking at semaphore
     internal values??  if you're changing the semantics of this
     routine, are there any other callers that need to be changed?

nfx-tree/code/ssc-genlib/linux.h

     looks good

nfx-tree/code/ssc-genlib/openbsd.h

     looks good

