Re: GEOM/libdisk problem on pc98

2002-11-07 Thread Takahashi Yoshihiro
In article [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:

 I wonder at why pc98 disks don't have their type ('ty') in the result
 of kern.geom.conftxt, but i386 disks have.
 
 Feel free to fix this and submit patches to me for review: I want
 to make sure we don't adversely affect the platforms which work at
 this late point i the release-process.

I have fixed to support pc98. Please review the attached patch.

---
TAKAHASHI Yoshihiro [EMAIL PROTECTED]

Index: geom_bsd.c
===
RCS file: /home/ncvs/src/sys/geom/geom_bsd.c,v
retrieving revision 1.29
diff -u -r1.29 geom_bsd.c
--- geom_bsd.c  28 Oct 2002 07:50:47 -  1.29
+++ geom_bsd.c  7 Nov 2002 14:29:13 -
@@ -701,8 +701,13 @@
if (!error  i != 165  flags == G_TF_NORMAL)
break;
 
+   error = g_getattr(PC98::type, cp, i);
+   if (!error  i != 0xc494  flags == G_TF_NORMAL)
+   break;
+
ms-mbroffset = 0;
g_getattr(MBR::offset, cp, ms-mbroffset);
+   g_getattr(PC98::offset, cp, ms-mbroffset);
 
/* Get sector size, we need it to read data. */
secsize = cp-provider-sectorsize;
Index: geom_pc98.c
===
RCS file: /home/ncvs/src/sys/geom/geom_pc98.c,v
retrieving revision 1.17
diff -u -r1.17 geom_pc98.c
--- geom_pc98.c 4 Nov 2002 06:30:38 -   1.17
+++ geom_pc98.c 7 Nov 2002 14:22:59 -
@@ -32,53 +32,108 @@
  * $FreeBSD: src/sys/geom/geom_pc98.c,v 1.17 2002/11/04 06:30:38 phk Exp $
  */
 
-
 #include sys/param.h
-#include sys/stdint.h
 #ifndef _KERNEL
+#include signal.h
 #include stdio.h
-#include string.h
 #include stdlib.h
-#include signal.h
+#include string.h
 #include err.h
 #else
 #include sys/systm.h
 #include sys/kernel.h
-#include sys/conf.h
-#include sys/bio.h
 #include sys/malloc.h
+#include sys/bio.h
 #include sys/lock.h
 #include sys/mutex.h
 #endif
-#include sys/stdint.h
+
+#include sys/diskpc98.h
 #include geom/geom.h
 #include geom/geom_slice.h
-#include machine/endian.h
 
 #define PC98_CLASS_NAME PC98
 
+static void
+g_dec_dos_partition(u_char *ptr, struct dos_partition *d)
+{
+   int i;
+
+   d-dp_mid = ptr[0];
+   d-dp_sid = ptr[1];
+   d-dp_dum1 = ptr[2];
+   d-dp_dum2 = ptr[3];
+   d-dp_ipl_sct = ptr[4];
+   d-dp_ipl_head = ptr[5];
+   d-dp_ipl_cyl = g_dec_le2(ptr + 6);
+   d-dp_ssect = ptr[8];
+   d-dp_shd = ptr[9];
+   d-dp_scyl = g_dec_le2(ptr + 10);
+   d-dp_esect = ptr[12];
+   d-dp_ehd = ptr[13];
+   d-dp_ecyl = g_dec_le2(ptr + 14);
+   for (i = 0; i  sizeof(d-dp_name); i++)
+   d-dp_name[i] = ptr[16 + i];
+}
+
 struct g_pc98_softc {
-   int foo;
+   int type [NDOSPART];
+   struct dos_partition dospart[NDOSPART];
 };
 
 static int
 g_pc98_start(struct bio *bp)
 {
+   struct g_provider *pp;
struct g_geom *gp;
-   struct g_pc98_softc *ms;
+   struct g_pc98_softc *mp;
struct g_slicer *gsp;
+   int index;
 
-   gp = bp-bio_to-geom;
+   pp = bp-bio_to;
+   index = pp-index;
+   gp = pp-geom;
gsp = gp-softc;
-   ms = gsp-softc;
+   mp = gsp-softc;
+   if (bp-bio_cmd == BIO_GETATTR) {
+   if (g_handleattr_int(bp, PC98::type, mp-type[index]))
+   return (1);
+   if (g_handleattr_off_t(bp, PC98::offset,
+  gsp-slices[index].offset))
+   return (1);
+   }
return (0);
 }
 
 static void
-g_pc98_dumpconf(struct sbuf *sb, char *indent, struct g_geom *gp, struct g_consumer 
*cp __unused, struct g_provider *pp)
+g_pc98_dumpconf(struct sbuf *sb, char *indent, struct g_geom *gp,
+   struct g_consumer *cp __unused, struct g_provider *pp)
 {
+   struct g_pc98_softc *mp;
+   struct g_slicer *gsp;
 
+   gsp = gp-softc;
+   mp = gsp-softc;
g_slice_dumpconf(sb, indent, gp, cp, pp);
+   if (pp != NULL) {
+   if (indent == NULL)
+   sbuf_printf(sb,  ty %d, mp-type[pp-index]);
+   else
+   sbuf_printf(sb, %stype%d/type\n, indent,
+   mp-type[pp-index]);
+   }
+}
+
+static void
+g_pc98_print(int i, struct dos_partition *dp)
+{
+
+   g_hexdump(dp, sizeof(dp[0]));
+   printf([%d] mid:%d(0x%x) sid:%d(0x%x),
+  i, dp-dp_mid, dp-dp_mid, dp-dp_sid, dp-dp_sid);
+   printf( s:%d/%d/%d, dp-dp_scyl, dp-dp_shd, dp-dp_ssect);
+   printf( e:%d/%d/%d, dp-dp_ecyl, dp-dp_ehd, dp-dp_esect);
+   printf( name:%s\n, dp-dp_name);
 }
 
 static struct g_geom *
@@ -88,19 +143,19 @@
struct g_consumer *cp;
struct g_provider *pp2;
int error, i, npart;
-   u_char *buf, *p;
+   struct dos_partition dp[NDOSPART];

Re: GEOM/libdisk problem on pc98

2002-11-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Takahashi Yoshihiro
 writes:

I have fixed to support pc98. Please review the attached patch.

COOL!  Thanks!

The geom_bsd.c change looks entirely reasonable and is OK with me:
commit it.

The geom_pc98 change looks like a major step i the right direction,
but I don't really have a chance to judge its correctness, so if you
think it is an improvement, you just commit it.

Thankyou very very much!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: GEOM/libdisk problem on pc98

2002-11-06 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: In message [EMAIL PROTECTED], Takahashi Yoshihiro 
: writes:
: The test program for libdisk is a failure in pc98 disks.
: 
: I wonder at why pc98 disks don't have their type ('ty') in the result
: of kern.geom.conftxt, but i386 disks have.
: 
: I still have practically no documentation of the PC98 format and no
: hardware I can test on, so I am pretty unable to do anything sane.

I have translated some Japanese docs that I was able to find, through
the kind assistance of kawanobe-san.  I took a trip to the local
technical library, but the articles he pointed me at were unavailable.
I'll be happy to continue to translate docs that help explain the
format.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: GEOM/libdisk problem on pc98

2002-11-06 Thread Soeren Schmidt
It seems M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Poul-Henning Kamp [EMAIL PROTECTED] writes:
 : In message [EMAIL PROTECTED], Takahashi Yoshihiro 
 : writes:
 : The test program for libdisk is a failure in pc98 disks.
 : 
 : I wonder at why pc98 disks don't have their type ('ty') in the result
 : of kern.geom.conftxt, but i386 disks have.
 : 
 : I still have practically no documentation of the PC98 format and no
 : hardware I can test on, so I am pretty unable to do anything sane.
 
 I have translated some Japanese docs that I was able to find, through
 the kind assistance of kawanobe-san.  I took a trip to the local
 technical library, but the articles he pointed me at were unavailable.
 I'll be happy to continue to translate docs that help explain the
 format.

Could you mail me a copy as well please ?
It seems that GEOM works on PC98 with the ATA driver, but I'm still
having stability problems so they are not in -current yet...

-Søren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: GEOM/libdisk problem on pc98

2002-11-06 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], M. Warner Losh writes:
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: In message [EMAIL PROTECTED], Takahashi Yoshihiro 
: writes:
: The test program for libdisk is a failure in pc98 disks.
: 
: I wonder at why pc98 disks don't have their type ('ty') in the result
: of kern.geom.conftxt, but i386 disks have.
: 
: I still have practically no documentation of the PC98 format and no
: hardware I can test on, so I am pretty unable to do anything sane.

I have translated some Japanese docs that I was able to find, through
the kind assistance of kawanobe-san.  I took a trip to the local
technical library, but the articles he pointed me at were unavailable.
I'll be happy to continue to translate docs that help explain the
format.

The stuff you sent me was absolutely a big help, despite the fact that
only one or two of the disk-images people have sent me were actually
in compliance with that document, at least it validated what I did
on those.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



GEOM/libdisk problem on pc98

2002-11-04 Thread Takahashi Yoshihiro
The test program for libdisk is a failure in pc98 disks.

I wonder at why pc98 disks don't have their type ('ty') in the result
of kern.geom.conftxt, but i386 disks have.

#./tst01 da0
PC98 [da0s1] 2 40958
error = -1
BSD [da0s1b] 2 1024
error = 310
BSD [da0s1a] 1026 39934
error = 310
c 0x8062040
c-p 0x8062080
c-p-p 0x0
--==##==--
Debug_Disk(da0)  bios_geom=0/8/128 = 0
  boot1=0x0, boot2=0x0, bootipl=0x0, bootmenu=0x0
--0x80620400 40031712 40031711 da0  - ??   0x00 
  --  0x80620800 40031712 40031711 -- unused   0x00 



kern.geom.conftxt: 0 DISK da0 20496236544 512 hd 8 sc 128
1 PC98 da0s1 10736893952 512 i 0 o 524288
2 BSD da0s1c 10736893952 512 i 2 o 0
2 BSD da0s1b 268435456 512 i 1 o 0
2 BSD da0s1a 10468458496 512 i 0 o 268435456
0 DISK wd2 1281925120 512 hd 8 sc 17
1 PC98 wd2s1 1281368064 512 i 0 o 69632
0 DISK wd1 426774528 512 hd 8 sc 17
1 PC98 wd1s1 425730048 512 i 0 o 69632
2 BSD wd1s1e 225378304 512 i 4 o 201326592
2 BSD wd1s1c 426704896 512 i 2 o 0
2 BSD wd1s1b 134217728 512 i 1 o 67108864
2 BSD wd1s1a 67108864 512 i 0 o 0
0 DISK wd0 3228696576 512 hd 8 sc 17
1 PC98 wd0s1 3228626944 512 i 0 o 69632
2 BSD wd0s1e 2154885120 512 i 4 o 1073741824
2 BSD wd0s1c 3228626944 512 i 2 o 0
2 BSD wd0s1b 536870912 512 i 1 o 536870912
2 BSD wd0s1a 536870912 512 i 0 o 0


---
TAKAHASHI Yoshihiro [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: GEOM/libdisk problem on pc98

2002-11-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Takahashi Yoshihiro 
writes:
The test program for libdisk is a failure in pc98 disks.

I wonder at why pc98 disks don't have their type ('ty') in the result
of kern.geom.conftxt, but i386 disks have.

I still have practically no documentation of the PC98 format and no
hardware I can test on, so I am pretty unable to do anything sane.

Feel free to fix this and submit patches to me for review: I want
to make sure we don't adversely affect the platforms which work at
this late point i the release-process.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message