Re: Workaround for data corruption issue with ALI M5229 IDE chip used with Sun Blade 100/Netra X1.
On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote: The following diff is ported from NetBSD (the workaround originated from OpenSolaris) to workaround the issue of data corruption with the ALI M5229 IDE chipset when using UltraDMA. Same workaround is also used by FreeBSD/Linux. This chipset is found in some sparc64 systems such as the Blade 100 and Netra X1. I don't have any such systems but I went digging for this being curious why the nasty hack was added to the kernel configs to disable UltraDMA to workaround this bug and thus penalizing other IDE/SATA controllers that could be in the same system. If you have one of the mentioned systems please test this. My Blade 150 which has this controller seems to survive a make build with this. Before the patch: pciide0 at pci0 dev 13 function 0 Acer Labs M5229 UDMA IDK rev 0xc3: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7cc for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: WDC WD400BB-22DEA0 atapiscsi0 at pciide0 channel 0 drive 1 wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) after: pciide0 at pci0 dev 13 function 0 Acer Labs M5229 UDMA IDK rev 0xc3: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7cc for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: WDC WD400BB-22DEA0 atapiscsi0 at pciide0 channel 0 drive 1 wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) -- Matthieu Herrb
Add support for RDC R6040 10/100 Ethernet driver vte(4)
Hello, The patch at http://www.kevlo.org/vte.diff adds support for RDC R6040 10/100 Ethernet device. Please test if you have that device and send feedback directly to me, thanks! Tested on eBox-3300MX. # dmesg | grep vte vte0 at pci0 dev 8 function 0 RDC R6040 Ethernet rev 0x00: irq 3, address 00:1b:eb:68:43:cc rdcphy0 at vte0 phy 1: R6040 10/100 PHY, rev. 1 Kevin
Re: bioctl should retry passphrase
On Fri, Jan 14, 2011 at 07:10, Christopher Zimmermann
madro...@zakweb.de wrote:
On 01/14/11 00:51, Ted Unangst wrote:
If I type the wrong password into bioctl at boot, disks don't exist,
filesystems don't get mounted, and generally lots of things go wrong. All
I need is a second chance to remind me to type the right password.
In /etc/rc I simply do this:
[...]
# XXX - my own changes - enable encrypted softraid
echo -n 'wd0p '
until bioctl -c C -l /dev/wd0p softraid0
do echo -n 'try again wd0p '
done
# Check parity on raid devices.
raidctl -P all
swapctl -A -t blk
Christopher
Index: bioctl.c
===
RCS file: /home/tedu/cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.98
diff -u -r1.98 bioctl.c
--- bioctl.c 1 Dec 2010 19:40:18 - 1.98
+++ bioctl.c 13 Jan 2011 23:47:24 -
@@ -699,6 +699,7 @@
int rv, no_dev, fd;
dev_t *dt;
u_int16_t min_disks = 0;
+ int retry = 0;
if (!dev_list)
errx(1, no devices specified);
@@ -738,6 +739,7 @@
if (level == 'C' no_dev != min_disks)
errx(1, not exactly one partition);
+again:
memset(create, 0, sizeof(create));
create.bc_cookie = bl.bl_cookie;
create.bc_level = level;
@@ -802,8 +804,14 @@
memset(kdfinfo, 0, sizeof(kdfinfo));
memset(create, 0, sizeof(create));
if (rv == -1) {
- if (errno == EPERM)
+ if (errno == EPERM) {
+ if (!retry) {
+ warnx(Incorrect passphrase. Try again.);
+ retry = 1;
+ goto again;
+ }
errx(1, Incorrect passphrase);
+ }
err(1, BIOCCREATERAID);
}
This might be a flag in bioctl to force looping until the password is
correct. This way, you can force correct pasword for /usr, /var or
other and keep the current behaviour for partition like
/home/user1/encypted
I only have the former so my /etc/rc contains:
if [ X${bioctl_flags} != XNO ]; then
trap '' EXIT TERM KILL
echo 'mounting softraid'; until bioctl
$bioctl_flags 2/dev/null ; do done
trap - EXIT TERM KILL
fi
# Check parity on raid devices.
raidctl -P all
--
Thomas Jeunet
Re: msk(4) diff needs testing.
From: Brad b...@comstyle.com
Date: Thu, 13 Jan 2011 19:59:27 -0500
On Saturday 17 April 2010 13:59:56 Brad wrote:
Please test the following diff with any msk(4) adapters.
Just check that the interfaces are working before and after
applying the diff.
This corrects the interrupt moderation timer ticks setting
for the various generations of chipsets so that the
SK_IM_USECS() macro works properly when used elsewhere in
the code.
Plase provide a dmesg.
This was tested with the following chipsets but it could use a bit more
testing on other ASIC revisions other than the Yukon-2 EC Ultra. Please
test especially if you have a Yukon-2 FE or Yukon-2 FE+ based chipset.
mskc0 at pci4 dev 0 function 0 Marvell Yukon 88E8056 rev 0x12, Yukon-2 EC
Ultra rev. B0 (0x3): apic 4 int 17 (irq 10)
mskc0 at pci3 dev 0 function 0 Marvell Yukon 88E8058 rev 0x13, Yukon-2 EC
Ultra rev. B0 (0x3): apic 1 int 17 (irq 7)
And *how* exactly was this tested? Did anybody actually provide you
with benchmarks showing that this has no impact on the throughput (in
pps and bps) and interrupt load on the CPU?
Index: if_msk.c
===
RCS file: /cvs/src/sys/dev/pci/if_msk.c,v
retrieving revision 1.86
diff -u -p -r1.86 if_msk.c
--- if_msk.c9 Jan 2010 02:40:18 - 1.86
+++ if_msk.c17 Apr 2010 17:39:18 -
@@ -754,10 +754,21 @@ mskc_reset(struct sk_softc *sc)
*/
switch (sc-sk_type) {
case SK_YUKON_EC:
- case SK_YUKON_XL:
- case SK_YUKON_FE:
+ case SK_YUKON_EC_U:
+ case SK_YUKON_EX:
+ case SK_YUKON_SUPR:
+ case SK_YUKON_ULTRA2:
imtimer_ticks = SK_IMTIMER_TICKS_YUKON_EC;
break;
+ case SK_YUKON_FE:
+ imtimer_ticks = SK_IMTIMER_TICKS_YUKON_FE;
+ break;
+ case SK_YUKON_FE_P:
+ imtimer_ticks = SK_IMTIMER_TICKS_YUKON_FE_P;
+ break;
+ case SK_YUKON_XL:
+ imtimer_ticks = SK_IMTIMER_TICKS_YUKON_XL;
+ break;
default:
imtimer_ticks = SK_IMTIMER_TICKS_YUKON;
}
Index: if_skreg.h
===
RCS file: /cvs/src/sys/dev/pci/if_skreg.h,v
retrieving revision 1.53
diff -u -p -r1.53 if_skreg.h
--- if_skreg.h 29 Mar 2009 14:36:34 - 1.53
+++ if_skreg.h 4 Mar 2010 00:15:36 -
@@ -394,9 +394,12 @@
#define SK_IMCTL_START 0x04
/* Number of ticks per usec for interrupt moderation */
+#define SK_IMTIMER_TICKS_YUKON_FE_P50
#define SK_IMTIMER_TICKS_GENESIS 53
#define SK_IMTIMER_TICKS_YUKON 78
+#define SK_IMTIMER_TICKS_YUKON_FE 100
#define SK_IMTIMER_TICKS_YUKON_EC 125
+#define SK_IMTIMER_TICKS_YUKON_XL 156
#define SK_IM_USECS(x) ((x) * imtimer_ticks)
/*
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Workaround for data corruption issue with ALI M5229 IDE chip used with Sun Blade 100/Netra X1.
Date: Fri, 14 Jan 2011 09:00:09 +0100 From: Matthieu Herrb matthieu.he...@laas.fr On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote: The following diff is ported from NetBSD (the workaround originated from OpenSolaris) to workaround the issue of data corruption with the ALI M5229 IDE chipset when using UltraDMA. Same workaround is also used by FreeBSD/Linux. This chipset is found in some sparc64 systems such as the Blade 100 and Netra X1. I don't have any such systems but I went digging for this being curious why the nasty hack was added to the kernel configs to disable UltraDMA to workaround this bug and thus penalizing other IDE/SATA controllers that could be in the same system. If you have one of the mentioned systems please test this. My Blade 150 which has this controller seems to survive a make build with this. The big question of course is whether it will survive a make build with the change that removes the restriction of only using Ultra-DMA up to mode 2, but without the fixes in pciide.c. Beware, that might actually eat your filesystem.
Re: Workaround for data corruption issue with ALI M5229 IDE chip used with Sun Blade 100/Netra X1.
On 14 January 2011 09:11, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Fri, 14 Jan 2011 09:00:09 +0100 From: Matthieu Herrb matthieu.he...@laas.fr On Wed, Jan 12, 2011 at 08:32:12PM -0500, Brad wrote: The following diff is ported from NetBSD (the workaround originated from OpenSolaris) to workaround the issue of data corruption with the ALI M5229 IDE chipset when using UltraDMA. Same workaround is also used by FreeBSD/Linux. This chipset is found in some sparc64 systems such as the Blade 100 and Netra X1. I don't have any such systems but I went digging for this being curious why the nasty hack was added to the kernel configs to disable UltraDMA to workaround this bug and thus penalizing other IDE/SATA controllers that could be in the same system. If you have one of the mentioned systems please test this. My Blade 150 which has this controller seems to survive a make build with this. The big question of course is whether it will survive a make build with the change that removes the restriction of only using Ultra-DMA up to mode 2, but without the fixes in pciide.c. Beware, that might actually eat your filesystem. Even so, can't we force udma 2 for that chipset only ? considering the fix in pciide isn't enough. Thing is I ran into this problem with a sili 3114 (pciide) in an ultra 5, had to manually change the wd flags to get past UDMA2.
Re: Support for size multipliers in newfs/mount_mfs
On 01/14/11 03:12, Vadim Zhukov wrote: On 14 January 2011 ?. 02:46:49 Alexander Hall wrote: On 01/13/11 14:48, Vadim Zhukov wrote: @@ -230,10 +232,12 @@ from its default will make it impossible to find the alternate superblocks if the standard superblock is lost. .It Fl s Ar size -The size of the file system in sectors. -This value is multiplied by the number of 512\-byte blocks in a sector -to yield the size of the file system in 512\-byte blocks, which is the value -used by the kernel. +The size of the file system. +The argument may contain a multiplier, as documented in +.Xr scan_scaled 3 . +If multiplier was not specified then this value is multiplied by the number of +512\-byte blocks in a sector to yield the size of the file system in +512\-byte blocks (not bytes!), which is the value used by the kernel. Can someone explain to me why the manpage needs to explain all of this internal mumbo-jumbo? It just confused me. Either it's sector size or it's in [KMGTP]. I was wandering this too... Tried to fix, see below. case 'S': - sectorsize = strtonum(optarg, 1, INT_MAX, errstr); - if (errstr) - fatal(sector size is %s: %s, errstr, optarg); + if (scan_scaled(optarg, sectorsize) == -1 || + sectorsize = 0 || sectorsize INT_MAX) + fatal(sector size: %s: %s, strerror(errno), errno will only be set if scan_scaled() failed. Yep. + optarg); break; case 'T': disktype = optarg; @@ -265,10 +267,18 @@ main(int argc, char *argv[]) quiet = 1; break; case 's': + /* +* We need to save scaled and unscaled value separately +* because unscaled is not representing bytes. +*/ + fssize_scaled = -1; /* in case of multiple -s */ fssize = strtonum(optarg, 1, LLONG_MAX, errstr); - if (errstr) - fatal(file system size is %s: %s, - errstr, optarg); + if (!errstr) + break; + if (strcmp(errstr, invalid) || + scan_scaled(optarg, fssize_scaled) == -1 || + fssize_scaled = 0) + fatal(file system size is %s: %s, errstr, optarg); same here Double-yep. The fixed patch, implementing Ted's suggestions too, is below. I still have to use separate variable, fssize_input, but now it is the one always initialized in the argument parsing loop, and fssize is set up based on fssize_input and sectorsize - after we could calculate sectorsize itself. -- Best wishes, Vadim Zhukov A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Yawn... Index: newfs.8 === RCS file: /cvs/src/sbin/newfs/newfs.8,v retrieving revision 1.68 diff -u -p -r1.68 newfs.8 --- newfs.8 21 Mar 2010 07:51:23 - 1.68 +++ newfs.8 14 Jan 2011 02:09:52 - @@ -218,6 +218,8 @@ With this option, will not print extraneous information like superblock backups. .It Fl S Ar sector-size The size of a sector in bytes (almost always 512). +The argument may contain a multiplier, as documented in +.Xr scan_scaled 3 . A sector is the smallest addressable unit on the physical device. Changing this is useful only when using .Nm @@ -230,11 +232,14 @@ from its default will make it impossible to find the alternate superblocks if the standard superblock is lost. .It Fl s Ar size -The size of the file system in sectors. -This value is multiplied by the number of 512\-byte blocks in a sector -to yield the size of the file system in 512\-byte blocks, which is the value -used by the kernel. -The maximum size of an FFS file system is 2,147,483,647 (2^31 \- 1) of these +The size of the file system. +The argument may contain a multiplier, as documented in +.Xr scan_scaled 3 . +If multiplier was not specified then this value is interpreted as number of +sectors (see +.Fl S ) , +not number of bytes. I'm not entirely happy with that... Maybe jmc@ can help? I'd suggest something even simpler: If no multiplier is present, .Ar size represents the number of sectors (see .Fl S ) . +The maximum size of an FFS file system is 2,147,483,647 (2^31 \- 1) of 512\-byte blocks, slightly less than 1 TB. FFS2 file systems can be as large as 64 PB. Note however that for Index: newfs.c === RCS file: /cvs/src/sbin/newfs/newfs.c,v
softraid: factor out block I/O code
The following diff factors out the block I/O code that is used within
softraid(4) and also allows it to handle I/Os that exceeds MAXPHYS in
size. This is necessary for some upcoming work.
This diff needs extensive testing since the main purpose is to read and
write the softraid metadata. Bugs in this area will eat softraid metadata
and therefore destroy softraid volumes. If you are testing please ensure
that you have backed up your data or that the volume does not have
critical information. Please report test successes/failures directly to me.
Index: softraidvar.h
===
RCS file: /cvs/src/sys/dev/softraidvar.h,v
retrieving revision 1.96
diff -u -p -r1.96 softraidvar.h
--- softraidvar.h 6 Nov 2010 23:01:56 - 1.96
+++ softraidvar.h 6 Jan 2011 12:41:26 -
@@ -624,6 +624,8 @@ int sr_check_io_collision(struct sr_wo
void sr_scsi_done(struct sr_discipline *,
struct scsi_xfer *);
intsr_chunk_in_use(struct sr_softc *, dev_t);
+intsr_rw(struct sr_softc *, dev_t, char *, size_t,
+ daddr64_t, long);
/* discipline functions */
intsr_raid_inquiry(struct sr_workunit *);
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.217
diff -u -p -r1.217 softraid.c
--- softraid.c 20 Dec 2010 17:47:48 - 1.217
+++ softraid.c 6 Jan 2011 12:41:26 -
@@ -387,57 +387,93 @@ sr_meta_getdevname(struct sr_softc *sc,
}
int
-sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t sz,
-daddr64_t ofs, long flags)
+sr_rw(struct sr_softc *sc, dev_t dev, char *buf, size_t size, daddr64_t
offset,
+long flags)
{
- struct sr_softc *sc = sd-sd_sc;
+ struct vnode*vp;
struct buf b;
+ size_t bufsize;
int rv = 1;
- DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
- DEVNAME(sc), dev, md, sz, ofs, flags);
-
- bzero(b, sizeof(b));
+ DNPRINTF(SR_D_MISC, %s: sr_rw(0x%x, %p, %d, %llu 0x%x)\n,
+ DEVNAME(sc), dev, buf, size, offset, flags);
- if (md == NULL) {
- printf(%s: read invalid metadata pointer\n, DEVNAME(sc));
+ if (bdevvp(dev, vp)) {
+ printf(%s: sr_rw: failed to allocate vnode\n, DEVNAME(sc));
goto done;
}
- b.b_flags = flags | B_PHYS;
- b.b_blkno = ofs;
- b.b_bcount = sz;
- b.b_bufsize = sz;
- b.b_resid = sz;
- b.b_data = md;
- b.b_error = 0;
- b.b_proc = curproc;
- b.b_dev = dev;
- b.b_iodone = NULL;
- if (bdevvp(dev, b.b_vp)) {
- printf(%s: sr_meta_rw: can't allocate vnode\n, DEVNAME(sc));
- goto done;
- }
- if ((b.b_flags B_READ) == 0)
- b.b_vp-v_numoutput++;
-
- LIST_INIT(b.b_dep);
- VOP_STRATEGY(b);
- biowait(b);
-
- if (b.b_flags B_ERROR) {
- printf(%s: 0x%x i/o error on block %llu while reading
- metadata %d\n, DEVNAME(sc), dev, b.b_blkno, b.b_error);
- goto done;
+
+ while (size 0) {
+
+ DNPRINTF(SR_D_MISC, %s: buf %p, size %d, offset %llu)\n,
+ DEVNAME(sc), buf, size, offset);
+
+ bufsize = (size MAXPHYS) ? MAXPHYS : size;
+
+ bzero(b, sizeof(b));
+
+ b.b_flags = flags | B_PHYS;
+ b.b_proc = curproc;
+ b.b_dev = dev;
+ b.b_iodone = NULL;
+ b.b_error = 0;
+ b.b_blkno = offset;
+ b.b_data = buf;
+ b.b_bcount = bufsize;
+ b.b_bufsize = bufsize;
+ b.b_resid = bufsize;
+ b.b_vp = vp;
+
+ if ((b.b_flags B_READ) == 0)
+ vp-v_numoutput++;
+
+ LIST_INIT(b.b_dep);
+ VOP_STRATEGY(b);
+ biowait(b);
+
+ if (b.b_flags B_ERROR) {
+ printf(%s: I/O error %d on dev 0x%x at block %llu\n,
+ DEVNAME(sc), b.b_error, dev, b.b_blkno);
+ goto done;
+ }
+
+ size -= bufsize;
+ buf += bufsize;
+ offset += howmany(bufsize, DEV_BSIZE);
+
}
+
rv = 0;
+
done:
- if (b.b_vp)
- vput(b.b_vp);
+ if (vp)
+ vput(vp);
return (rv);
}
int
+sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t size,
+daddr64_t offset, long flags)
+{
+ int rv = 1;
+
+ DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
+ DEVNAME(sd-sd_sc), dev,
Planchita mas Secador de regalo
$ 280 Pesos Planchita Gama + Secador Elite Combo Especial para Regalar / 1 Plancha para Cabello Ga.Ma Italy Ceramic Laser ION / 1 Secador Elite Mini 1400W
Re: bioctl should retry passphrase
On Fri, Jan 14, 2011 at 12:57 AM, Joel Sing j...@sing.id.au wrote: On Friday 14 January 2011, Ted Unangst wrote: If I type the wrong password into bioctl at boot, disks don't exist, filesystems don't get mounted, and generally lots of things go wrong. All I need is a second chance to remind me to type the right password. Huh? Both you and Marco rejected this last year and when I last checked there was no bioctl included in /etc/rc... I guess we need to decide if bioctl should behave like su/passwd, sudo or like something else. Oh, hmm, I guess experience changes everything. :) But that patch also made the user pick how many retries they wanted. I still think that's silly. Most things give you second chances, but I can't think of anything that requires a command line switch to do so.
Novità finanziarie
Se non visualizzi bene news clicca qui /P remove mail
Update UTF-8 locale ctype data (was: Re: ls(1) multibyte support)
On Thu, Jan 06, 2011 at 07:52:19PM +0300, Alexander Polakov wrote: * Alexander Polakov polac...@gmail.com [110105 17:20]: Hi, here's an updated version. 1) en_US.UTF-8.src updates from FreeBSD Let's start with those. These changes are all fine, I checked them against Unicode 5.2. http://www.unicode.org/Public/5.2.0/charts/CodeCharts-noHan.pdf The diff below (from Alexander) brings us up to par with FreeBSD. Many updates could be made to this file to support additional characters listed in Unicode 5.2.0 (or even 6.0.0). But that can be done later. Can someone ok this? Thanks in advance. Index: share/locale/ctype/en_US.UTF-8.src === RCS file: /OpenBSD/src/share/locale/ctype/en_US.UTF-8.src,v retrieving revision 1.1 diff -u -r1.1 en_US.UTF-8.src --- share/locale/ctype/en_US.UTF-8.src 7 Aug 2005 10:03:45 - 1.1 +++ share/locale/ctype/en_US.UTF-8.src 6 Jan 2011 16:24:39 - @@ -491,9 +491,9 @@ * U+0300 - U+036F : Combining Diacritical Marks */ -GRAPH 0x0300 - 0x034f 0x0360 - 0x036f -PRINT 0x0300 - 0x034f 0x0360 - 0x036f -SWIDTH1 0x0300 - 0x034f 0x0360 - 0x036f +GRAPH 0x0300 - 0x034e 0x0350 - 0x036f +PRINT 0x0300 - 0x034e 0x0350 - 0x036f +SWIDTH0 0x0300 - 0x034e 0x0350 - 0x036f MAPUPPER 0x0345 0x0399 @@ -583,7 +583,7 @@ LOWER 0x04c8 0x04ca 0x04cc 0x04ce 0x04d1 0x04d3 0x04d5 LOWER 0x04d7 0x04d9 0x04db 0x04dd 0x04df 0x04e1 0x04e3 LOWER 0x04e5 0x04e7 0x04e9 0x04eb 0x04ed 0x04ef 0x04f1 -LOWER 0x04f3 0x04f5 0x04f9 +LOWER 0x04f3 0x04f5 0x04f7 0x04f9 PUNCT 0x0482 UPPER 0x0400 - 0x042f 0x0460 0x0462 0x0464 0x0466 0x0468 UPPER 0x046a 0x046c 0x046e 0x0470 0x0472 0x0474 0x0476 @@ -595,9 +595,10 @@ UPPER 0x04c5 0x04c7 0x04c9 0x04cb 0x04cd 0x04d0 0x04d2 UPPER 0x04d4 0x04d6 0x04d8 0x04da 0x04dc 0x04de 0x04e0 UPPER 0x04e2 0x04e4 0x04e6 0x04e8 0x04ea 0x04ec 0x04ee -UPPER 0x04f0 0x04f2 0x04f4 0x04f8 -PRINT 0x0400 - 0x0486 0x0488 - 0x04ce 0x04d0 - 0x04f5 0x04f8 0x04f9 -SWIDTH1 0x0400 - 0x0486 0x0488 - 0x04ce 0x04d0 - 0x04f5 0x04f8 0x04f9 +UPPER 0x04f0 0x04f2 0x04f4 0x04f6 0x04f8 +PRINT 0x0400 - 0x0486 0x0488 - 0x04ce 0x04d0 - 0x04f9 +SWIDTH0 0x0483 - 0x0486 0x0488 - 0x0489 +SWIDTH1 0x0400 - 0x0482 0x048a - 0x04ce 0x04d0 - 0x04f9 MAPUPPER 0x0430 - 0x044f : 0x0410 MAPUPPER 0x0450 - 0x045f : 0x0400 @@ -671,6 +672,7 @@ MAPUPPER 0x04f1 0x04f0 MAPUPPER 0x04f3 0x04f2 MAPUPPER 0x04f5 0x04f4 +MAPUPPER 0x04f7 0x04f6 MAPUPPER 0x04f9 0x04f8 MAPLOWER 0x0400 - 0x040f : 0x0450 MAPLOWER 0x0410 - 0x042f : 0x0430 @@ -744,6 +746,7 @@ MAPLOWER 0x04f0 0x04f1 MAPLOWER 0x04f2 0x04f3 MAPLOWER 0x04f4 0x04f5 +MAPLOWER 0x04f6 0x04f7 MAPLOWER 0x04f8 0x04f9 @@ -1052,7 +1055,8 @@ GRAPH 0x0e01 - 0x0e3a 0x0e3f - 0x0e5b PUNCT 0x0e3f 0x0e4f 0x0e5a 0x0e5b PRINT 0x0e01 - 0x0e3a 0x0e3f - 0x0e5b -SWIDTH1 0x0e01 - 0x0e3a 0x0e3f - 0x0e5b +SWIDTH0 0x0e31 0x0e34 - 0x0e3a 0x0e47 - 0x0e4e +SWIDTH1 0x0e01 - 0x0e30 0x0e32 - 0x0e33 0x0e3f - 0x0e46 0x0e4f - 0x0e5b TODIGIT0x0e50 - 0x0e59 : 0x @@ -1283,6 +1287,14 @@ TODIGIT0x1810 - 0x1819 : 0x +/* + * U+1DC0 - U+1DFF : Combining Diacritical Marks Supplement + */ + +GRAPH 0x1DC0 - 0x1DC3 +PRINT 0x1DC0 - 0x1DC3 +SWIDTH0 0x1DC0 - 0x1DC3 + /* * U+1E00 - U+1EFF : Latin Extended Additional @@ -1672,7 +1684,8 @@ BLANK 0x2000 - 0x200b 0x202f 0x205f PRINT 0x2000 - 0x200b 0x2010 - 0x2029 0x202f - 0x2052 0x2057 PRINT 0x205f -SWIDTH1 0x2000 - 0x200b 0x2010 - 0x2029 0x202f - 0x2052 0x2057 +SWIDTH1 0x2000 - 0x200a 0x2010 - 0x2029 0x202f - 0x2052 0x2057 +SWIDTH0 0x200b - 0x200d SWIDTH1 0x205f @@ -1707,9 +1720,9 @@ * U+20D0 - U+20FF : Combining Diacritical Marks for Symbols */ -GRAPH 0x20d0 - 0x20ea -PRINT 0x20d0 - 0x20ea -SWIDTH1 0x20d0 - 0x20ea +GRAPH 0x20d0 - 0x20eb +PRINT 0x20d0 - 0x20eb +SWIDTH0 0x20d0 - 0x20eb /* @@ -1987,7 +2000,8 @@ PUNCT 0x309b 0x309c PRINT 0x3041 - 0x3096 0x3099 - 0x309f PHONOGRAM 0x3041 - 0x3096 0x309f -SWIDTH2 0x3041 - 0x3096 0x3099 - 0x309f +SWIDTH0 0x3099 - 0x309a +SWIDTH2 0x3041 - 0x3096 0x309b - 0x309f /* @@ -2211,7 +2225,7 @@ GRAPH 0xfe20 - 0xfe23 PRINT 0xfe20 - 0xfe23 -SWIDTH1 0xfe20 - 0xfe23 +SWIDTH0 0xfe20 - 0xfe23 /* @@ -2333,8 +2347,13 @@ GRAPH 0x1d100 - 0x1d126 0x1d12a - 0x1d172 0x1d17b - 0x1d1dd PUNCT 0x1d100 - 0x1d126 0x1d12a - 0x1d164 0x1d16a - 0x1d16c PUNCT 0x1d183 0x1d184 0x1d18c - 0x1d1a9 0x1d1ae - 0x1d1dd -PRINT 0x1d100 - 0x1d126 0x1d12a - 0x1d172 0x1d17b - 0x1d1dd -SWIDTH1 0x1d100 - 0x1d126 0x1d12a - 0x1d172 0x1d17b - 0x1d1dd +PRINT 0x1d100 - 0x1d126 0x1d12a - 0x1d158 0x1d15a - 0x1d172 +PRINT 0x1d17b - 0x1d1dd +SWIDTH0 0x1d165
Naučite da flertujete
Top Shop Top E-revija: 58, 14. januar 2011. PraktiD na reÅ¡enja i saveti za bolji Eivot Budi fit | Lepota | Zdrav Eivot | DomaDinstvo Zabava i deca | Svi proizvodi | Knjige | Saveti i zabava Top Shop HIT TV proizvodi! Door Gym Xtreme - fitnes rekvizit Door Gym Xtreme Relax Tone ruD ni masaEer Relax Tone Spider Pan - set tiganja Spider pan - set tiganja Ab Tronic X2 - Pojas za stomak Ab Tronic X2 Cardio twister - Kardio steper Kardio steper NauD ite da flertujete NauD ite kako se suptilno flertuje, oslobodite se blama i nauD ite da zavodite... Zdravo mrÅ¡avljenje Saznajte 8 osnovnih principa zdravog i efikasnog skidanja kilograma... 10 greÅ¡aka u podizanju mladih Ne brinite se - sledeDih 10 saveta De vam makar malo pomoDi... Saznajte da li ste opsednuti hranom Ljudi nezadovoljni svojim izgledom suoD eni su sa najviÅ¡e poremeDaja u ishrani... MuÅ¡karci i Eene - paEnja! NauD ite da flertujete Svi smo u Eivotu flertovali - doduÅ¡e neki viÅ¡e, a neki manje. Flert je suptilna manifestacija naÅ¡e borbe za osobu suprotnog pola, a ta borba nam je u genima. No kako mnogi od nas i uspevaju u tome, je sporno pitanje. [ViÅ¡e informacija] Walk Maxx Fitnes patike b: DoÅ¡etajte do top forme b: ZateEite miÅ¡iDe svakim korakom b: Super figura bez muke! PoruD ite ovde Walk Maxx Fitnes patike Najpopularnije u Novoj godini! Pillow pets - PliÅ¡ana igraD ka i jastuk Paint zoom - kompresor za kreD enje Velform Perfect Legs - krema za noge Pillow pets - PliÅ¡ana igraD ka ... Paint zoom - kompresor za kreD enje Velform Perfect Legs - krema za ... Najbolji pliÅ¡ani ljubimci za vaÅ¡e maliÅ¡ane! Odaberite izmeDu 4 razliD ita ljubimca! Kompresor za jednostavno i temeljno farbanje svih povrÅ¡ina. RasprÅ¡ite farbu gde god Eelite! Biljna formula koja pouzdano ublaEava i spreD ava pojavu ispucalih kapilara i proÅ¡irenih vena. Cena: 2.290 RSD [ViÅ¡e informacija] Cena: 7.490 RSD [ViÅ¡e informacija] Cena: 2.690 RSD [ViÅ¡e informacija] Zdravo mrÅ¡avljenje Zdravo mrÅ¡avljenje PokuÅ¡ali ste bezbroj dijeta i dali previÅ¡e novca za fitnes centre i naporne treninge, a ne vidite rezultate? Verovatno radite neÅ¡to pogreÅ¡no⦠Pratite sledeDih 8 saveta za uspeÅ¡no skidanje kilograma. [ViÅ¡e informacija] Jednostavno i praktiD no Water Jet - kompresor za vodu Rina's 90 - priruD nik za mrÅ¡avljenje Space Bag Cube Set - kockaste vakuum vreDe Water Jet - kompresor za vodu Rina s 90 - priruD nik za mrÅ¡avljenje Space Bag Cube Set - kockaste ... 50% Pretvorite obiD no baÅ¡tansko crevo u moDan kompresor za pranje i D iÅ¡Denje! Lako i povoljno reÅ¡enje. Ovaj evropski bestseler â priruD nik za mrÅ¡avljenje promenio je Eivot mnogima. Proverite zaÅ¡to! OdloEite garderobu i posteljinu na mali prostor i zaÅ¡titite je od vlage, moljaca i spoljnih mirisa. Cena: 1.290 RSD [ViÅ¡e informacija] Cena: 699 RSD [ViÅ¡e informacija] Cena: 2.690 RSD [ViÅ¡e informacija] 10 greÅ¡aka u podizanju mladih 10 greÅ¡aka u podizanju mladih Imate (problematiD nog) tinejdEera kod kuDe? Kosa vam polako sedi, a nemate pojma o tome Å¡ta treba ili ne treba uraditi? A uskoro i Å¡kola poD inje opet, Å¡to situaciju samo D ini gorom... Ne brinite se - sledeDih 10 saveta De vam makar malo pomoDi... [ViÅ¡e informacija] Novo, praktiD no, povoljno... Ecogenie Ball - Kugla za maÅ¡insko pranje veÅ¡a Mini pegla na paru sa dodacima - Steam Brush Kartica za Klub 5* Ecogenie Ball - Kugla za maÅ¡insko ... Mini pegla na paru sa dodacima ... Kartica za Klub 5* Eko kugle pomoDu kojih moEete maÅ¡inski prati veÅ¡ bez deterdEenta. Super uÅ¡teda! Ova pegla na paru je idealna za brzo peglanje uz mnogo manje napora i najveDih komada veÅ¡a. Postanite D lan kluba odabranih i odmah zapoD nite sa povoljnom kupovinom! Cena: 5.490 RSD [ViÅ¡e informacija] Cena: 1.990 RSD [ViÅ¡e informacija] Cena: 2.290 RSD [ViÅ¡e informacija] 7 znakova koji pokazuju da previÅ¡e ... Saznajte da li ste opsednuti hranom ProseD na Eena razmiÅ¡lja o svom izgledu osam puta dnevno, a 80% njih su nezadovoljne. SliD no je i sa muÅ¡karcima... MeDutim, upravo ljudi nezadovoljni svojim izgledom suoD eni su sa najviÅ¡e poremeDaja u ishrani. [ViÅ¡e informacija] Za lepÅ¡i i zdraviji Eivot Velform Enhance Bra Zidni sat - Å areni kvadrat Dry Cooker Delimano - keramiD ki Dry Cooker Velform Enhance Bra Zidni sat - Å areni kvadrat Dry Cooker Delimano - keramiD ki ... 29% Ovaj prsluk podiEe VaÅ¡e grudi, oblikuje ih i D ini potpuno senzualnim. Za izazovan dekolte... Dekorativan zidni sat Eivih boja, izuzetno lepog dizajna ulepÅ¡aDe VaÅ¡ Eivotni prostor. Nova generacija posuDa - keramiD ki tiganj za pripremanje zdrave hrane bez masnoDe. Cena: 2.490 RSD [ViÅ¡e informacija] Cena: 1.990 RSD [ViÅ¡e informacija] Cena: 3.690 RSD [ViÅ¡e informacija] Ovu elektronsku poÅ¡tu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu na nekom od sajtova Top Shop-a, uD estvovali u naÅ¡oj poklon igri ili nagradnom kvizu ili se prijavili za e-D
Re: softraid: factor out block I/O code
This one needs lots of testing folks. Please oblige.
On Sat, Jan 15, 2011 at 01:22:24AM +1100, Joel Sing wrote:
The following diff factors out the block I/O code that is used within
softraid(4) and also allows it to handle I/Os that exceeds MAXPHYS in
size. This is necessary for some upcoming work.
This diff needs extensive testing since the main purpose is to read and
write the softraid metadata. Bugs in this area will eat softraid metadata
and therefore destroy softraid volumes. If you are testing please ensure
that you have backed up your data or that the volume does not have
critical information. Please report test successes/failures directly to me.
Index: softraidvar.h
===
RCS file: /cvs/src/sys/dev/softraidvar.h,v
retrieving revision 1.96
diff -u -p -r1.96 softraidvar.h
--- softraidvar.h 6 Nov 2010 23:01:56 - 1.96
+++ softraidvar.h 6 Jan 2011 12:41:26 -
@@ -624,6 +624,8 @@ int sr_check_io_collision(struct
sr_wo
void sr_scsi_done(struct sr_discipline *,
struct scsi_xfer *);
int sr_chunk_in_use(struct sr_softc *, dev_t);
+int sr_rw(struct sr_softc *, dev_t, char *, size_t,
+ daddr64_t, long);
/* discipline functions */
int sr_raid_inquiry(struct sr_workunit *);
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.217
diff -u -p -r1.217 softraid.c
--- softraid.c20 Dec 2010 17:47:48 - 1.217
+++ softraid.c6 Jan 2011 12:41:26 -
@@ -387,57 +387,93 @@ sr_meta_getdevname(struct sr_softc *sc,
}
int
-sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t sz,
-daddr64_t ofs, long flags)
+sr_rw(struct sr_softc *sc, dev_t dev, char *buf, size_t size, daddr64_t
offset,
+long flags)
{
- struct sr_softc *sc = sd-sd_sc;
+ struct vnode*vp;
struct buf b;
+ size_t bufsize;
int rv = 1;
- DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
- DEVNAME(sc), dev, md, sz, ofs, flags);
-
- bzero(b, sizeof(b));
+ DNPRINTF(SR_D_MISC, %s: sr_rw(0x%x, %p, %d, %llu 0x%x)\n,
+ DEVNAME(sc), dev, buf, size, offset, flags);
- if (md == NULL) {
- printf(%s: read invalid metadata pointer\n, DEVNAME(sc));
+ if (bdevvp(dev, vp)) {
+ printf(%s: sr_rw: failed to allocate vnode\n, DEVNAME(sc));
goto done;
}
- b.b_flags = flags | B_PHYS;
- b.b_blkno = ofs;
- b.b_bcount = sz;
- b.b_bufsize = sz;
- b.b_resid = sz;
- b.b_data = md;
- b.b_error = 0;
- b.b_proc = curproc;
- b.b_dev = dev;
- b.b_iodone = NULL;
- if (bdevvp(dev, b.b_vp)) {
- printf(%s: sr_meta_rw: can't allocate vnode\n, DEVNAME(sc));
- goto done;
- }
- if ((b.b_flags B_READ) == 0)
- b.b_vp-v_numoutput++;
-
- LIST_INIT(b.b_dep);
- VOP_STRATEGY(b);
- biowait(b);
-
- if (b.b_flags B_ERROR) {
- printf(%s: 0x%x i/o error on block %llu while reading
- metadata %d\n, DEVNAME(sc), dev, b.b_blkno, b.b_error);
- goto done;
+
+ while (size 0) {
+
+ DNPRINTF(SR_D_MISC, %s: buf %p, size %d, offset %llu)\n,
+ DEVNAME(sc), buf, size, offset);
+
+ bufsize = (size MAXPHYS) ? MAXPHYS : size;
+
+ bzero(b, sizeof(b));
+
+ b.b_flags = flags | B_PHYS;
+ b.b_proc = curproc;
+ b.b_dev = dev;
+ b.b_iodone = NULL;
+ b.b_error = 0;
+ b.b_blkno = offset;
+ b.b_data = buf;
+ b.b_bcount = bufsize;
+ b.b_bufsize = bufsize;
+ b.b_resid = bufsize;
+ b.b_vp = vp;
+
+ if ((b.b_flags B_READ) == 0)
+ vp-v_numoutput++;
+
+ LIST_INIT(b.b_dep);
+ VOP_STRATEGY(b);
+ biowait(b);
+
+ if (b.b_flags B_ERROR) {
+ printf(%s: I/O error %d on dev 0x%x at block %llu\n,
+ DEVNAME(sc), b.b_error, dev, b.b_blkno);
+ goto done;
+ }
+
+ size -= bufsize;
+ buf += bufsize;
+ offset += howmany(bufsize, DEV_BSIZE);
+
}
+
rv = 0;
+
done:
- if (b.b_vp)
- vput(b.b_vp);
+ if (vp)
+ vput(vp);
return (rv);
}
int
+sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t size,
+daddr64_t offset, long flags)
+{
+ int rv = 1;
+
Re: http gzip support for ftp
On Sun, Jan 09, 2011 at 04:21:51PM -0500, Ted Unangst wrote: Downloading things can go a lot faster if the server and client support http compression. This is easily added to the ftp program's http support. It consists of two parts. Support for deflating the data we receive and support for the chunked transfer the server will use to send data to us. The chunked supported is probably useful in its own right as well. How does it work if you use http to transfer already compressed files ? Does it need special intelligence to avoid compressing things again ? Remember that a lot of people do pkg_add over http. We definitely do NOT want to recompress packages that are already .tgz...
Re: softraid: factor out block I/O code
Or to reiterate - if you want this working in 4.9 now is the time to
make time to test it :)
On 14 January 2011 09:42, Marco Peereboom sl...@peereboom.us wrote:
This one needs lots of testing folks. Please oblige.
On Sat, Jan 15, 2011 at 01:22:24AM +1100, Joel Sing wrote:
The following diff factors out the block I/O code that is used within
softraid(4) and also allows it to handle I/Os that exceeds MAXPHYS in
size. This is necessary for some upcoming work.
This diff needs extensive testing since the main purpose is to read and
write the softraid metadata. Bugs in this area will eat softraid metadata
and therefore destroy softraid volumes. If you are testing please ensure
that you have backed up your data or that the volume does not have
critical information. Please report test successes/failures directly to
me.
Index: softraidvar.h
===
RCS file: /cvs/src/sys/dev/softraidvar.h,v
retrieving revision 1.96
diff -u -p -r1.96 softraidvar.h
--- softraidvar.h 6 Nov 2010 23:01:56 - 1.96
+++ softraidvar.h 6 Jan 2011 12:41:26 -
@@ -624,6 +624,8 @@ int sr_check_io_collision(struct
sr_wo
void sr_scsi_done(struct sr_discipline *,
struct scsi_xfer *);
int sr_chunk_in_use(struct sr_softc *, dev_t);
+int sr_rw(struct sr_softc *, dev_t, char *, size_t,
+ daddr64_t, long);
/* discipline functions */
int sr_raid_inquiry(struct sr_workunit *);
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.217
diff -u -p -r1.217 softraid.c
--- softraid.c20 Dec 2010 17:47:48 - 1.217
+++ softraid.c6 Jan 2011 12:41:26 -
@@ -387,57 +387,93 @@ sr_meta_getdevname(struct sr_softc *sc,
}
int
-sr_meta_rw(struct sr_discipline *sd, dev_t dev, void *md, size_t sz,
-daddr64_t ofs, long flags)
+sr_rw(struct sr_softc *sc, dev_t dev, char *buf, size_t size, daddr64_t
offset,
+long flags)
{
- struct sr_softc *sc = sd-sd_sc;
+ struct vnode*vp;
struct buf b;
+ size_t bufsize;
int rv = 1;
- DNPRINTF(SR_D_META, %s: sr_meta_rw(0x%x, %p, %d, %llu 0x%x)\n,
- DEVNAME(sc), dev, md, sz, ofs, flags);
-
- bzero(b, sizeof(b));
+ DNPRINTF(SR_D_MISC, %s: sr_rw(0x%x, %p, %d, %llu 0x%x)\n,
+ DEVNAME(sc), dev, buf, size, offset, flags);
- if (md == NULL) {
- printf(%s: read invalid metadata pointer\n, DEVNAME(sc));
+ if (bdevvp(dev, vp)) {
+ printf(%s: sr_rw: failed to allocate vnode\n,
DEVNAME(sc));
goto done;
}
- b.b_flags = flags | B_PHYS;
- b.b_blkno = ofs;
- b.b_bcount = sz;
- b.b_bufsize = sz;
- b.b_resid = sz;
- b.b_data = md;
- b.b_error = 0;
- b.b_proc = curproc;
- b.b_dev = dev;
- b.b_iodone = NULL;
- if (bdevvp(dev, b.b_vp)) {
- printf(%s: sr_meta_rw: can't allocate vnode\n,
DEVNAME(sc));
- goto done;
- }
- if ((b.b_flags B_READ) == 0)
- b.b_vp-v_numoutput++;
-
- LIST_INIT(b.b_dep);
- VOP_STRATEGY(b);
- biowait(b);
-
- if (b.b_flags B_ERROR) {
- printf(%s: 0x%x i/o error on block %llu while reading
- metadata %d\n, DEVNAME(sc), dev, b.b_blkno,
b.b_error);
- goto done;
+
+ while (size 0) {
+
+ DNPRINTF(SR_D_MISC, %s: buf %p, size %d, offset %llu)\n,
+ DEVNAME(sc), buf, size, offset);
+
+ bufsize = (size MAXPHYS) ? MAXPHYS : size;
+
+ bzero(b, sizeof(b));
+
+ b.b_flags = flags | B_PHYS;
+ b.b_proc = curproc;
+ b.b_dev = dev;
+ b.b_iodone = NULL;
+ b.b_error = 0;
+ b.b_blkno = offset;
+ b.b_data = buf;
+ b.b_bcount = bufsize;
+ b.b_bufsize = bufsize;
+ b.b_resid = bufsize;
+ b.b_vp = vp;
+
+ if ((b.b_flags B_READ) == 0)
+ vp-v_numoutput++;
+
+ LIST_INIT(b.b_dep);
+ VOP_STRATEGY(b);
+ biowait(b);
+
+ if (b.b_flags B_ERROR) {
+ printf(%s: I/O error %d on dev 0x%x at block
%llu\n,
+ DEVNAME(sc), b.b_error, dev, b.b_blkno);
+ goto done;
+ }
+
+ size -= bufsize;
+ buf += bufsize;
+ offset += howmany(bufsize, DEV_BSIZE);
+
}
+
rv = 0;
+
done:
- if (b.b_vp)
- vput(b.b_vp);
+ if (vp)
+ vput(vp);
return (rv);
}
int
Re: http gzip support for ftp
On Fri, Jan 14, 2011 at 12:08 PM, Marc Espie es...@nerim.net wrote: On Sun, Jan 09, 2011 at 04:21:51PM -0500, Ted Unangst wrote: Downloading things can go a lot faster if the server and client support http compression. This is easily added to the ftp program's http support. It consists of two parts. Support for deflating the data we receive and support for the chunked transfer the server will use to send data to us. The chunked supported is probably useful in its own right as well. How does it work if you use http to transfer already compressed files ? Does it need special intelligence to avoid compressing things again ? Remember that a lot of people do pkg_add over http. We definitely do NOT want to recompress packages that are already .tgz... That is totally up to the server. Most are configured to only compress known file types, like html, text, css, ...
Re: Workaround for data corruption issue with ALI M5229 IDE chip used with Sun Blade 100/Netra X1.
The big question of course is whether it will survive a make build with the change that removes the restriction of only using Ultra-DMA up to mode 2, but without the fixes in pciide.c. Beware, that might actually eat your filesystem. I'm doing this right now. I'm running a make build as we speak. I'm not sure when it should fuck up the filesystem. before: pciide0 at pci0 dev 13 function 0 Acer Labs M5229 UDMA IDE rev 0xc3: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7cc for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: ST340014A wd0: 16-sector PIO, LBA48, 38166MB, 78165360 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 wd1 at pciide0 channel 1 drive 0: ST340014A wd1: 16-sector PIO, LBA48, 38166MB, 78165360 sectors wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 after: pciide0: using ivec 0x7cc for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: ST340014A wd0: 16-sector PIO, LBA48, 38166MB, 78165360 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 wd1 at pciide0 channel 1 drive 0: ST340014A wd1: 16-sector PIO, LBA48, 38166MB, 78165360 sectors wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 diff i used: Index: arch/sparc64/conf/GENERIC === RCS file: /home/cvs/src/sys/arch/sparc64/conf/GENERIC,v retrieving revision 1.261 diff -u -p -r1.261 GENERIC --- arch/sparc64/conf/GENERIC 12 Dec 2010 14:33:57 - 1.261 +++ arch/sparc64/conf/GENERIC 11 Jan 2011 23:41:06 - @@ -381,7 +381,7 @@ stty* at spif? sbpp* at spif? pciide*at pci? flags 0x -wd*at pciide? flags 0x0a00 +wd*at pciide? flags 0x atapiscsi* at pciide? scsibus* at atapiscsi? Index: arch/sparc64/conf/RAMDISK === RCS file: /home/cvs/src/sys/arch/sparc64/conf/RAMDISK,v retrieving revision 1.98 diff -u -p -r1.98 RAMDISK --- arch/sparc64/conf/RAMDISK 19 Apr 2010 10:44:33 - 1.98 +++ arch/sparc64/conf/RAMDISK 11 Jan 2011 23:41:13 - @@ -151,7 +151,7 @@ ti* at sbus? gem* at sbus? pciide*at pci? flags 0x -wd*at pciide? flags 0x0a00 +wd*at pciide? flags 0x atapiscsi* at pciide? scsibus* at atapiscsi? Index: arch/sparc64/conf/RAMDISKU5 === RCS file: /home/cvs/src/sys/arch/sparc64/conf/RAMDISKU5,v retrieving revision 1.16 diff -u -p -r1.16 RAMDISKU5 --- arch/sparc64/conf/RAMDISKU5 24 Jun 2009 11:38:40 - 1.16 +++ arch/sparc64/conf/RAMDISKU5 11 Jan 2011 23:41:30 - @@ -55,7 +55,7 @@ pcons0at mainbus0 # PROM console timer* at mainbus0 # Timer chip (some systems) pciide*at pci? flags 0x -wd*at pciide? flags 0x0a00 +wd*at pciide? flags 0x atapiscsi* at pciide? scsibus* at atapiscsi?
Re: http gzip support for ftp
On Fri, Jan 14, 2011 at 06:08:54PM +0100, Marc Espie wrote: On Sun, Jan 09, 2011 at 04:21:51PM -0500, Ted Unangst wrote: Downloading things can go a lot faster if the server and client support http compression. This is easily added to the ftp program's http support. It consists of two parts. Support for deflating the data we receive and support for the chunked transfer the server will use to send data to us. The chunked supported is probably useful in its own right as well. How does it work if you use http to transfer already compressed files ? Does it need special intelligence to avoid compressing things again ? It just asks the server that it may compress the content. The server logic is normally either MIME type specific or configured to exclude certain extensions. Joerg
cwm: maximization and alt-tab bug
There's a bug in cwm that screws up alt-tab if you follow the set of events
described in the next paragraph. To regain alt-tab functionality you need
to jerk the mouse around to focus clients and then it usually comes back to
its senses again.
So, start with a clean root window. Spawn two xterms, A and B, and place
them side-by-side at the top of the screen. Focus B and vertically maximize
it. Move ptr *near* bottom of B (below its original bottom y position).
Alt-tab to focus A. Alt-tab to focus B. Vertically unmaximize B (ptr will
now be over the root window) and alt-tab to A. Now alt-tab will not focus B
and the ptr will be somewhere at the bottom of the root window. Can anyone
else reproduce this?
It took a while to figure out the sequence of events that triggered this
problem and there might be other ways it can be triggered. The same
happens if you maximize (fullscreen) or horizontally maximize the window
and move the ptr.
This patch fixes the problem for me.
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.76
diff -u -p -r1.76 client.c
--- client.c22 May 2010 22:10:31 - 1.76
+++ client.c14 Jan 2011 17:27:39 -
@@ -273,6 +273,7 @@ client_maximize(struct client_ctx *cc)
if (cc-flags CLIENT_MAXIMIZED) {
cc-geom = cc-savegeom;
+ cc-ptr.x = cc-ptr.y = -1;
} else {
if (!(cc-flags (CLIENT_VMAXIMIZED | CLIENT_HMAXIMIZED)))
cc-savegeom = cc-geom;
@@ -312,6 +313,7 @@ client_vertmaximize(struct client_ctx *c
if (cc-flags CLIENT_VMAXIMIZED) {
cc-geom = cc-savegeom;
+ cc-ptr.x = cc-ptr.y = -1;
} else {
if (!(cc-flags (CLIENT_MAXIMIZED | CLIENT_HMAXIMIZED)))
cc-savegeom = cc-geom;
@@ -343,6 +345,7 @@ client_horizmaximize(struct client_ctx *
if (cc-flags CLIENT_HMAXIMIZED) {
cc-geom = cc-savegeom;
+ cc-ptr.x = cc-ptr.y = -1;
} else {
if (!(cc-flags (CLIENT_MAXIMIZED | CLIENT_VMAXIMIZED)))
cc-savegeom = cc-geom;
mg: join-line
Here's another command I always miss while working with mg.
diff -up src/usr.bin/mg.old/def.h src/usr.bin/mg/def.h
--- src/usr.bin/mg.old/def.hFri Jan 14 17:27:17 2011
+++ src/usr.bin/mg/def.hFri Jan 14 17:49:34 2011
@@ -512,6 +512,7 @@ int forwdel(int, int);
int backdel(int, int);
int space_to_tabstop(int, int);
int backtoindent(int, int);
+int joinline(int, int);
/* extend.c X */
int insert(int, int);
diff -up src/usr.bin/mg.old/funmap.c src/usr.bin/mg/funmap.c
--- src/usr.bin/mg.old/funmap.c Fri Jan 14 17:27:17 2011
+++ src/usr.bin/mg/funmap.c Fri Jan 14 17:50:55 2011
@@ -103,6 +103,7 @@ static struct funmap functnames[] = {
{fillword, insert-with-wrap,},
{backisearch, isearch-backward,},
{forwisearch, isearch-forward,},
+ {joinline, join-line,},
{justone, just-one-space,},
{ctrlg, keyboard-quit,},
{killbuffer_cmd, kill-buffer,},
diff -up src/usr.bin/mg.old/keymap.c src/usr.bin/mg/keymap.c
--- src/usr.bin/mg.old/keymap.c Fri Jan 14 18:41:34 2011
+++ src/usr.bin/mg/keymap.c Fri Jan 14 17:52:04 2011
@@ -228,7 +228,7 @@ static PF metasqf[] = {
NULL, /* [ */
delwhite, /* \ */
rescan, /* ] */
- rescan, /* ^ */
+ joinline, /* ^ */
rescan, /* _ */
rescan, /* ` */
rescan, /* a */
diff -up src/usr.bin/mg.old/mg.1 src/usr.bin/mg/mg.1
--- src/usr.bin/mg.old/mg.1 Fri Jan 14 17:27:17 2011
+++ src/usr.bin/mg/mg.1 Fri Jan 14 18:35:02 2011
@@ -220,6 +220,8 @@ beginning-of-buffer
end-of-buffer
.It M-\e
delete-horizontal-space
+.It M-^
+join-line
.It M-b
backward-word
.It M-c
@@ -510,6 +512,9 @@ Use incremental searching, initially in the forward di
isearch ignores any explicit arguments.
If invoked during macro definition or evaluation, the non-incremental
search-forward is invoked instead.
+.It join-line
+Join the current line to the previous. If called with an argument,
+join the next line to the current one.
.It just-one-space
Delete any whitespace around dot, then insert a space.
.It keyboard-quit
diff -up src/usr.bin/mg.old/random.c src/usr.bin/mg/random.c
--- src/usr.bin/mg.old/random.c Fri Jan 14 17:27:17 2011
+++ src/usr.bin/mg/random.c Fri Jan 14 18:45:16 2011
@@ -453,3 +453,31 @@ backtoindent(int f, int n)
++curwp-w_doto;
return (TRUE);
}
+
+/*
+ * Join the current line to the previous, or with arg, the next line
+ * to the current one. If the former line is not empty, leave exactly
+ * one space at the joint. Otherwise, leave no whitespace.
+ */
+int
+joinline(int f, int n)
+{
+ int doto;
+
+ if (f FFARG) {
+ gotoeol(FFRAND, 1);
+ forwdel(FFRAND, 1);
+ } else {
+ gotobol(FFRAND, 1);
+ backdel(FFRAND, 1);
+ }
+
+ delwhite(FFRAND, 1);
+
+ if ((doto = curwp-w_doto) 0) {
+ linsert(1, ' ');
+ curwp-w_doto = doto;
+ }
+
+ return (TRUE);
+}
Re: Support for size multipliers in newfs/mount_mfs
On 14 January 2011 ?. 17:18:41 Alexander Hall wrote:
On 01/14/11 03:12, Vadim Zhukov wrote:
+If multiplier was not specified then this value is interpreted as number of
+sectors (see
+.Fl S ) ,
+not number of bytes.
I'm not entirely happy with that... Maybe jmc@ can help?
I'd suggest something even simpler:
If no multiplier is present,
.Ar size
represents the number of sectors (see
.Fl S ) .
I like it. :) It's in the new version of patch.
+The maximum size of an FFS file system is 2,147,483,647 (2^31 \- 1) of
512\-byte blocks, slightly less than 1 TB.
FFS2 file systems can be as large as 64 PB.
Note however that for
Index: newfs.c
===
RCS file: /cvs/src/sbin/newfs/newfs.c,v
retrieving revision 1.88
diff -u -p -r1.88 newfs.c
--- newfs.c 13 Dec 2010 00:02:58 - 1.88
+++ newfs.c 14 Jan 2011 02:09:52 -
@@ -114,7 +114,7 @@ int mfs;/* run as the memory
based fi
intNflag; /* run without writing file system */
intOflag = 1; /* 0 = 4.3BSD ffs, 1 = 4.4BSD ffs, 2 =
ffs2 */
daddr64_t fssize; /* file system size */
-intsectorsize; /* bytes/sector */
+long long sectorsize; /* bytes/sector */
intfsize = 0; /* fragment size */
intbsize = 0; /* block size */
intmaxfrgspercg = INT_MAX; /* maximum fragments per cylinder group
*/
@@ -169,6 +169,8 @@ main(int argc, char *argv[])
char **saveargv = argv;
int ffsflag = 1;
const char *errstr;
+ long long fssize_input;
+ int fssize_usebytes = 0;
if (strstr(__progname, mfs))
mfs = Nflag = quiet = 1;
@@ -192,9 +194,12 @@ main(int argc, char *argv[])
oflagset = 1;
break;
case 'S':
- sectorsize = strtonum(optarg, 1, INT_MAX, errstr);
- if (errstr)
- fatal(sector size is %s: %s, errstr, optarg);
+ if (scan_scaled(optarg, sectorsize) == -1)
+ fatal(sector size: %s: %s,
+ strerror(errno), optarg);
+ if (sectorsize = 0)
+ fatal(sector size is not positive: %s,
+ optarg);
break;
case 'T':
disktype = optarg;
@@ -265,10 +270,18 @@ main(int argc, char *argv[])
quiet = 1;
break;
case 's':
- fssize = strtonum(optarg, 1, LLONG_MAX, errstr);
- if (errstr)
+ if (scan_scaled(optarg, fssize_input) == -1)
fatal(file system size is %s: %s,
- errstr, optarg);
+ strerror(errno), optarg);
This looks strange;
-s xyz = file system size is invalid argument: zyx ?
+ if (fssize_input = 0)
+ fatal(file system size is not positive: %s,
+ optarg);
Do we really need different ways of just telling us that the size
argument is invalid?
Hm-m. Looks like you're right. Fixed.
if (scan_scaled(optarg, fssize_input) == -1 ||
fssize_input = 0)
fatal(invalid file system size);
(Up for discussion)
+ fssize_usebytes = 0;/* in case of multiple -s */
+ for (s1 = optarg; *s1 != '\0'; s1++)
+ if (isalpha(*s1)) {
+ fssize_usebytes = 1;
+ break;
+ }
break;
case 't':
fstype = optarg;
@@ -412,17 +425,25 @@ main(int argc, char *argv[])
argv[0], *cp);
}
havelabel:
- if (fssize == 0)
- fssize = DL_GETPSIZE(pp);
- if (fssize DL_GETPSIZE(pp) !mfs)
- fatal(%s: maximum file system size on the `%c' partition is
%lld,
- argv[0], *cp, DL_GETPSIZE(pp));
-
if (sectorsize == 0) {
sectorsize = lp-d_secsize;
if (sectorsize = 0)
fatal(%s: no default sector size, argv[0]);
}
+
+ if (fssize_usebytes) {
+ fssize = (daddr64_t)fssize_input / (daddr64_t)sectorsize;
+ if ((daddr64_t)fssize_input % (daddr64_t)sectorsize != 0)
+ fssize++;
+ } else if (fssize_input == 0)
+ fssize = DL_GETPSIZE(pp);
+ else
+ fssize = (daddr64_t)fssize_input;
+
+ if (fssize DL_GETPSIZE(pp) !mfs)
+
Re: Support for size multipliers in newfs/mount_mfs
On Fri, Jan 14, 2011 at 10:07:19PM +0300, Vadim Zhukov wrote: On 14 January 2011 ?. 17:18:41 Alexander Hall wrote: On 01/14/11 03:12, Vadim Zhukov wrote: +If multiplier was not specified then this value is interpreted as number of +sectors (see +.Fl S ) , +not number of bytes. I'm not entirely happy with that... Maybe jmc@ can help? I'd suggest something even simpler: If no multiplier is present, .Ar size represents the number of sectors (see .Fl S ) . I like it. :) It's in the new version of patch. i'd say that you'd be better leaving the description as it was (talking about sectors), then mentioning that a multiplier can also be used. i say this for a number of reasons: - the existing behaviour deals in sectors - the description of -S will then match - the mnemonic will be lost if you talk about sectors as being secondary jmc
Re: Support for size multipliers in newfs/mount_mfs
On 14 January 2011 ?. 23:15:13 Jason McIntyre wrote: On Fri, Jan 14, 2011 at 10:07:19PM +0300, Vadim Zhukov wrote: On 14 January 2011 ?. 17:18:41 Alexander Hall wrote: On 01/14/11 03:12, Vadim Zhukov wrote: +If multiplier was not specified then this value is interpreted as number of +sectors (see +.Fl S ) , +not number of bytes. I'm not entirely happy with that... Maybe jmc@ can help? I'd suggest something even simpler: If no multiplier is present, .Ar size represents the number of sectors (see .Fl S ) . I like it. :) It's in the new version of patch. i'd say that you'd be better leaving the description as it was (talking about sectors), then mentioning that a multiplier can also be used. i say this for a number of reasons: - the existing behaviour deals in sectors - the description of -S will then match - the mnemonic will be lost if you talk about sectors as being secondary Hm-m-m... okay, here is another try. Only manpage bits this time. There is one question on another topic: current newfs allows to specify sector size which is not aligned on 512-byte boundary. But kernel wants 512 byte blocks. So should be there done another rounding, errm, round? Like if (fs_size_in_bytes % DEV_BSIZE) fs_size_in_blocks++; Or should we just prohibit such sector sizes in newfs? -- Best wishes, Vadim Zhukov A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Index: newfs.8 === RCS file: /cvs/src/sbin/newfs/newfs.8,v retrieving revision 1.68 diff -u -p -r1.68 newfs.8 --- newfs.8 21 Mar 2010 07:51:23 - 1.68 +++ newfs.8 14 Jan 2011 21:39:00 - @@ -230,10 +230,18 @@ from its default will make it impossible to find the alternate superblocks if the standard superblock is lost. .It Fl s Ar size -The size of the file system in sectors. -This value is multiplied by the number of 512\-byte blocks in a sector +The size of the file system. +The argument may contain a multiplier, as documented in +.Xr scan_scaled 3 . +If no multiplier is present, +.Ar size +represents the number of sectors (see +.Fl S ) +and is multiplied by the number of 512\-byte blocks in a sector to yield the size of the file system in 512\-byte blocks, which is the value used by the kernel. +Otherwise, it is rounded up to next sector boundary and then again gets +converted to 512\-byte blocks count. The maximum size of an FFS file system is 2,147,483,647 (2^31 \- 1) of these 512\-byte blocks, slightly less than 1 TB. FFS2 file systems can be as large as 64 PB.
Re: Support for size multipliers in newfs/mount_mfs
On Sat, Jan 15, 2011 at 12:42:03AM +0300, Vadim Zhukov wrote: - the existing behaviour deals in sectors - the description of -S will then match - the mnemonic will be lost if you talk about sectors as being secondary Hm-m-m... okay, here is another try. Only manpage bits this time. no, i meant like below: There is one question on another topic: current newfs allows to specify sector size which is not aligned on 512-byte boundary. But kernel wants 512 byte blocks. So should be there done another rounding, errm, round? Like if (fs_size_in_bytes % DEV_BSIZE) fs_size_in_blocks++; Or should we just prohibit such sector sizes in newfs? -- Best wishes, Vadim Zhukov A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Index: newfs.8 === RCS file: /cvs/src/sbin/newfs/newfs.8,v retrieving revision 1.68 diff -u -p -r1.68 newfs.8 --- newfs.8 21 Mar 2010 07:51:23 - 1.68 +++ newfs.8 14 Jan 2011 21:39:00 - @@ -230,10 +230,18 @@ from its default will make it impossible to find the alternate superblocks if the standard superblock is lost. .It Fl s Ar size -The size of the file system in sectors. -This value is multiplied by the number of 512\-byte blocks in a sector +The size of the file system. +The argument may contain a multiplier, as documented in +.Xr scan_scaled 3 . +If no multiplier is present, +.Ar size +represents the number of sectors (see +.Fl S ) +and is multiplied by the number of 512\-byte blocks in a sector .It Fl s Ar size The size of the file system in sectors. This value is multiplied by the number of 512\-byte blocks in a sector ... used by the kernel. Alternatively .Ar size may instead use a multiplier, as documented in .Xr scan_scaled. The maximum size... does that make sense? jmc to yield the size of the file system in 512\-byte blocks, which is the value used by the kernel. +Otherwise, it is rounded up to next sector boundary and then again gets +converted to 512\-byte blocks count. The maximum size of an FFS file system is 2,147,483,647 (2^31 \- 1) of these 512\-byte blocks, slightly less than 1 TB. FFS2 file systems can be as large as 64 PB.
Re: Update UTF-8 locale ctype data (was: Re: ls(1) multibyte support)
On Fri, Jan 14, 2011 at 05:21:46PM +0100, Stefan Sperling wrote: On Thu, Jan 06, 2011 at 07:52:19PM +0300, Alexander Polakov wrote: * Alexander Polakov polac...@gmail.com [110105 17:20]: Hi, here's an updated version. 1) en_US.UTF-8.src updates from FreeBSD Let's start with those. These changes are all fine, I checked them against Unicode 5.2. http://www.unicode.org/Public/5.2.0/charts/CodeCharts-noHan.pdf The diff below (from Alexander) brings us up to par with FreeBSD. Many updates could be made to this file to support additional characters listed in Unicode 5.2.0 (or even 6.0.0). But that can be done later. Can someone ok this? Thanks in advance. Before the ctype changes can go in, we'll need to this part from Alexander's diff to fix mklocale (caught by nicm@, thanks!) These symbols are internal to libc, with exception of mklocale. Can this go in during ABI lock? Index: lib/libc/locale/runetype.h === RCS file: /OpenBSD/src/lib/libc/locale/runetype.h,v retrieving revision 1.5 diff -u -r1.5 runetype.h --- lib/libc/locale/runetype.h 8 Oct 2007 08:17:15 - 1.5 +++ lib/libc/locale/runetype.h 6 Jan 2011 16:24:20 - @@ -69,9 +69,9 @@ #define_RUNETYPE_I 0x0008U /* Ideogram */ #define_RUNETYPE_T 0x0010U /* Special */ #define_RUNETYPE_Q 0x0020U /* Phonogram */ -#define_RUNETYPE_SWM 0xc000U/* Mask to get screen width data */ +#define_RUNETYPE_SWM 0xe000U /* Mask to get screen width data */ #define_RUNETYPE_SWS 30 /* Bits to shift to get width */ -#define_RUNETYPE_SW0 0xU /* 0 width character */ +#define_RUNETYPE_SW0 0x2000U /* 0 width character */ #define_RUNETYPE_SW1 0x4000U /* 1 width character */ #define_RUNETYPE_SW2 0x8000U /* 2 width character */ #define_RUNETYPE_SW3 0xc000U /* 3 width character */
Make expr(1) 64-bit capable and radix-aware
Hi folks,
Here's a diff to expr(1) that does three things I feel make it more useful:
+ Makes it 64-bit capable on 64-bit architectures by changing relevant
int:s to long:s. I often use expr as a quick calculator for example when
partitioning disks and such, and frequently find myself up against the
32 bit signed integer limits.
+ Makes it able to use C-style radix prefixes to integers in order to do
calculations in octal and hexadecimal. In the olden days, early '80:s to
be specific, I worked at a company that produced a unix flavour called
D-NIX, which had this neat feature in its expr(1). It makes it a breeze
to make quick radix conversions, for example. And I guess the habit
stuck with me, for to this day it frustrates me not to be able to use
expr for that. :-) I hope others find it useful too. For example:
skynet:/usr/src/bin/expr# expr 0x1 + 15
131086
skynet:/usr/src/bin/expr#
+ Makes it able to output calculation results in hex and octal. This is
of course the reverse functionality to the previous. Works like this:
skynet:/usr/src/bin/expr# expr -x 16383
3fff
skynet:/usr/src/bin/expr# expr -o 16383
3
skynet:/usr/src/bin/expr# expr -X 16383
3FFF
skynet:/usr/src/bin/expr# expr -cx 16383
0x3fff
skynet:/usr/src/bin/expr#
Now, the downside is that the latter two changes will subtly change
expr:s semantics, in the following ways:
- Hexadecimal numbers (starting with 0x or 0X) is no longer recognized
as strings. (The common construct expr 'X'$FOO = 'X' would still work as
expected, of course.) Probably not a big concern.
- Since expr previously ignored switches altogether, strings starting
with '-' will no longer be recognized as strings, but probably generate
a usage: error message instead. This can be circumvented by the --
notation, and that particular form was actually supported before as
well. But still this might be a problem since there is a slim chance it
can break current shell scripts. I can't think of a better / more
backwards compatible way to implement different output radixes though.
- And of course the 32 bit signed integer edge cases will instead be 64
bit signed integer edge cases on 64-bit architectures. Probably not a
problem either.
- Oh, and I don't know if these changes breaks POSIX compliance.
(And as I'm about to post this at 04:00 in the morning, it comes to mind
that I might have read somewhere that submitted diffs should only change
one behaviour at a time. If that's the case I apologize.)
If these are worthy changes, they need testing of course (on both 32-
and 64-bit architectures), and if so I'll make a diff for the man page
as well. (And hopefully I didn't f*ck up the enclosed diff...)
Regards,
/Benny
88888 (cut)
Index: expr.c
===
RCS file: /cvs/src/bin/expr/expr.c,v
retrieving revision 1.17
diff -u -r1.17 expr.c
--- expr.c 21 Jun 2006 18:28:24 - 1.17
+++ expr.c 15 Jan 2011 03:00:26 -
@@ -14,11 +14,11 @@
#include regex.h
#include err.h
-struct val *make_int(int);
+struct val *make_int(long);
struct val *make_str(char *);
voidfree_value(struct val *);
-int is_integer(struct val *, int *);
-int to_integer(struct val *);
+int is_integer(struct val *, long *);
+longto_integer(struct val *);
voidto_string(struct val *);
int is_zero_or_null(struct val *);
voidnexttoken(int);
@@ -44,7 +44,7 @@
union {
char *s;
- int i;
+ longi;
} u;
};
@@ -53,7 +53,7 @@
char **av;
struct val *
-make_int(int i)
+make_int(long i)
{
struct val *vp;
@@ -92,11 +92,14 @@
/* determine if vp is an integer; if so, return it's value in *r */
int
-is_integer(struct val *vp, int *r)
+is_integer(struct val *vp, long *r)
{
char *s;
- int neg;
- int i;
+ longneg;
+ longi, d;
+ longradix=10;
+ static char *digits=0123456789abcdef;
+ char*dp;
if (vp-type == integer) {
*r = vp-u.i;
@@ -105,7 +108,8 @@
/*
* POSIX.2 defines an integer as an optional unary minus
-* followed by digits.
+* followed by digits. We also consider C style octal and
+* hexadecimal prefix notation part of an integer.
*/
s = vp-u.s;
i = 0;
@@ -113,14 +117,21 @@
neg = (*s == '-');
if (neg)
s++;
+ if (*s=='0') {
+ radix=8; s++;
+ if (*s=='x' || *s=='X') {
+ radix=16; s++;
+ }
+ }
while (*s) {
- if (!isdigit(*s))
+
Re: Make expr(1) 64-bit capable and radix-aware
+ Makes it 64-bit capable on 64-bit architectures by changing relevant int:s to long:s. I think this is a problem. I would expect a unix utility of this importance to work exactly the same on all our platforms.
Re: Make expr(1) 64-bit capable and radix-aware
On Fri, Jan 14, 2011 at 10:11 PM, Benny Lofgren bl-li...@lofgren.biz wrote: + Makes it 64-bit capable on 64-bit architectures by changing relevant int:s to long:s. I often use expr as a quick calculator for example when partitioning disks and such, and frequently find myself up against the 32 bit signed integer limits. I consider this a substantial regression actually. There's no reason for it to be machine dependent like this. Fortunately, the fix should be easy. Use int64_t everywhere and then everybody wins. The other changes seem useful, though others may care more about the posixness of it all. It'd be best to split this into the three different parts and submit as separate patches so we can discuss them individually.
expr(1) diff 2 of 3, make it able to accept c-style radix prefixes in integers
Hi,
Resubmitting the second change for review.
Recap:
+ Makes it able to use C-style radix prefixes to integers in order to do
calculations in octal and hexadecimal. In the olden days, early '80:s to
be specific, I worked at a company that produced a unix flavour called
D-NIX, which had this neat feature in its expr(1). It makes it a breeze
to make quick radix conversions, for example. And I guess the habit
stuck with me, for to this day it frustrates me not to be able to use
expr for that. :-) I hope others find it useful too. For example:
skynet:/usr/src/bin/expr# expr 0x1 + 15
131086
skynet:/usr/src/bin/expr#
- Hexadecimal numbers (starting with 0x or 0X) is no longer recognized
as strings. (The common construct expr 'X'$FOO = 'X' would still work as
expected, of course.) Probably not a big concern.
- POSIX?
/Benny
(This diff is done relative to the first, so if that one is out but this
one is in then I'll need to remake number 2.)
88888 (cut)
--- expr.c.diff1Sat Jan 15 04:35:43 2011
+++ expr.c Sat Jan 15 04:46:46 2011
@@ -96,7 +96,10 @@
{
char *s;
int64_t neg;
- int64_t i;
+ int64_t i, d;
+ int64_t radix=10;
+ static char *digits=0123456789abcdef;
+ char*dp;
if (vp-type == integer) {
*r = vp-u.i;
@@ -105,7 +108,8 @@
/*
* POSIX.2 defines an integer as an optional unary minus
-* followed by digits.
+* followed by digits. We also consider C style octal and
+* hexadecimal prefix notation part of an integer.
*/
s = vp-u.s;
i = 0;
@@ -113,14 +117,21 @@
neg = (*s == '-');
if (neg)
s++;
+ if (*s=='0') {
+ radix=8; s++;
+ if (*s=='x' || *s=='X') {
+ radix=16; s++;
+ }
+ }
while (*s) {
- if (!isdigit(*s))
+ if ((dp = strchr(digits, tolower(*s)))==NULL)
return 0;
+ if ((d = dp-digits) = radix)
+ return 0; /* Invalid digit for radix - string */
- i *= 10;
- i += *s - '0';
-
+ i *= radix;
+ i += d;
s++;
}
@@ -501,6 +512,13 @@
av = argv + 1;
nexttoken(0);
+
+ /* In case there is only one operand, make sure it is validated
+* as an integer as well, in case we for example want to print
+* it in a different radix.
+*/
+ (void) to_integer(tokval);
+
vp = eval0();
if (token != EOI) {
88888 (cut)
--
internetlabbet.se / work: +46 8 551 124 80 / Words must
Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed,
/ fax:+46 8 551 124 89/not counted.
/email: be...@internetlabbet.se
expr(1) diff 1 of 3, make it 64-bit capable
Hi,
Resubmitting the first of my three changes to expr(1) for review.
To recap from my original mail:
+ Makes it 64-bit capable on both 32- and 64-bit architectures by
changing relevant int:s to int64_t:s. I often use expr as a quick
calculator for example when partitioning disks and such, and frequently
find myself up against the 32 bit signed integer limits.
+ No longer has the drawback of different semantics on 32/64-bit.
- 32 bit signed integer edge cases will instead be 64 bit signed integer
edge cases. Hopefully not a problem. To my knowledge Solaris, Digital
Unix/Tru64/whatever and others are also 64-bit capable.
- Have no idea about POSIX compliance, but would be very surprised if
they specified 32-bit values only.
/Benny
88888 (cut)
Index: expr.c
===
RCS file: /cvs/src/bin/expr/expr.c,v
retrieving revision 1.17
diff -u -r1.17 expr.c
--- expr.c 21 Jun 2006 18:28:24 - 1.17
+++ expr.c 15 Jan 2011 03:37:40 -
@@ -14,11 +14,11 @@
#include regex.h
#include err.h
-struct val *make_int(int);
+struct val *make_int(int64_t);
struct val *make_str(char *);
voidfree_value(struct val *);
-int is_integer(struct val *, int *);
-int to_integer(struct val *);
+int is_integer(struct val *, int64_t *);
+int64_t to_integer(struct val *);
voidto_string(struct val *);
int is_zero_or_null(struct val *);
voidnexttoken(int);
@@ -44,7 +44,7 @@
union {
char *s;
- int i;
+ int64_t i;
} u;
};
@@ -53,7 +53,7 @@
char **av;
struct val *
-make_int(int i)
+make_int(int64_t i)
{
struct val *vp;
@@ -92,11 +92,11 @@
/* determine if vp is an integer; if so, return it's value in *r */
int
-is_integer(struct val *vp, int *r)
+is_integer(struct val *vp, int64_t *r)
{
char *s;
- int neg;
- int i;
+ int64_t neg;
+ int64_t i;
if (vp-type == integer) {
*r = vp-u.i;
@@ -133,10 +133,10 @@
/* coerce to vp to an integer */
-int
+int64_t
to_integer(struct val *vp)
{
- int r;
+ int64_t r;
if (vp-type == integer)
return 1;
@@ -375,7 +375,7 @@
{
struct val *l, *r;
enum token op;
- int v = 0, li, ri;
+ int64_t v = 0, li, ri;
l = eval3();
while ((op = token) == EQ || op == NE || op == LT || op == GT ||
@@ -509,7 +509,7 @@
}
if (vp-type == integer)
- printf(%d\n, vp-u.i);
+ printf(%ld\n, vp-u.i);
else
printf(%s\n, vp-u.s);
8888 (cut)
--
internetlabbet.se / work: +46 8 551 124 80 / Words must
Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed,
/ fax:+46 8 551 124 89/not counted.
/email: benny -at- internetlabbet.se
expr(1) diff 3 of 3, make it able to print result in different radixes
Hi,
Third change resubmit for review.
Recap:
+ Makes it able to output calculation results in hex and octal. This is
of course the reverse functionality to the previous. Works like this:
skynet:/usr/src/bin/expr# expr -x 16383
3fff
skynet:/usr/src/bin/expr# expr -o 16383
3
skynet:/usr/src/bin/expr# expr -X 16383
3FFF
skynet:/usr/src/bin/expr# expr -cx 16383
0x3fff
skynet:/usr/src/bin/expr#
- Since expr previously ignored switches altogether, strings starting
with '-' will no longer be recognized as strings, but probably generate
a usage: error message instead. This can be circumvented by the --
notation, and that particular form was actually supported before as
well. But still this might be a problem since there is a slim chance it
can break current shell scripts. I can't think of a better / more
backwards compatible way to implement different output radixes though.
- And of course POSIX, this everlasting spectre?
(This diff is done relative to the first two.)
88888 (cut)
--- expr.c.diff2Sat Jan 15 04:46:46 2011
+++ expr.c Sat Jan 15 04:50:45 2011
@@ -502,14 +502,39 @@
int
main(int argc, char *argv[])
{
- struct val *vp;
+ struct val *vp;
+ int oradix=10;
+ int cprefix=0;
+ int c;
+ extern char *__progname;
(void) setlocale(LC_ALL, );
- if (argc 1 !strcmp(argv[1], --))
- argv++;
+ while ((c=getopt(argc, argv, coxX)) != -1) {
+ switch (c) {
+ case 'c':
+ cprefix=1;
+ break;
+ case 'o':
+ oradix=8;
+ break;
+ case 'x':
+ oradix=16;
+ break;
+ case 'X':
+ oradix=-16;
+ break;
+ default:
+ fprintf(stderr,
+ usage: %s [-coxX] expression\n,
+ __progname);
+ exit(2); /* Tell user invalid expression */
+ }
+ }
+ argc -= optind;
+ argv += optind;
- av = argv + 1;
+ av = argv;
nexttoken(0);
@@ -526,9 +551,21 @@
/* NOTREACHED */
}
- if (vp-type == integer)
- printf(%ld\n, vp-u.i);
- else
+ if (vp-type == integer) {
+ switch (oradix) {
+ case 8:
+ printf(%s%lo\n, cprefix ? 0 : , vp-u.i);
+ break;
+ case 16:
+ printf(%s%lx\n, cprefix ? 0x : , vp-u.i);
+ break;
+ case -16:
+ printf(%s%lX\n, cprefix ? 0X : , vp-u.i);
+ break;
+ default:
+ printf(%ld\n, vp-u.i); break;
+ }
+ } else
printf(%s\n, vp-u.s);
exit(is_zero_or_null(vp));
88888 (cut)
--
internetlabbet.se / work: +46 8 551 124 80 / Words must
Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed,
/ fax:+46 8 551 124 89/not counted.
/email: benny -at- internetlabbet.se
Re: expr(1) diff 1 of 3, make it 64-bit capable
On Fri, Jan 14, 2011 at 8:08 PM, Benny Lofgren bl-li...@lofgren.biz wrote:
+ Makes it 64-bit capable on both 32- and 64-bit architectures by changing
relevant int:s to int64_t:s. I often use expr as a quick calculator for
example when partitioning disks and such, and frequently find myself up
against the 32 bit signed integer limits.
...
- Have no idea about POSIX compliance, but would be very surprised if they
specified 32-bit values only.
In my opinion, the requirement that POSIX states is not violated by this.
(The precise requirement can be found in section 1.1.2.1 of the XCU
section of POSIX 2008, where it says:
Integer variables and constants, including the values of operands and
option-arguments, used by the standard utilities listed in this
volume
of POSIX.1-2008 shall be implemented as equivalent to the ISO C
standard signed long data type; ...
...but I don't see a requirement for the compilation environment used
by the standard utilities to match any of the provided environments,
so as long as its a signed arithmetic with at least 31value bits (to
meet the ISO C requirements for signed long), it would appear to
comply.)
Index: expr.c
===
RCS file: /cvs/src/bin/expr/expr.c,v
retrieving revision 1.17
diff -u -r1.17 expr.c
If you're going to email diffs, you MUST turn off 'format=flowed', as
Thunderbird munged the whitespace on your diffs enough to make them
break with patch -l. Thunderbird has an option for that; find it
and use it.
...
-is_integer(struct val *vp, int *r)
+is_integer(struct val *vp, int64_t *r)
{
char *s;
- int neg;
- int i;
+ int64_t neg;
+ int64_t i;
You make 'neg' int64_t why?
...
@@ -509,7 +509,7 @@
}
if (vp-type == integer)
- printf(%d\n, vp-u.i);
+ printf(%ld\n, vp-u.i);
My crystal ball says you use amd64 platform and not i386, as the above
works on LP64 and fails on ILP32LL64. The format string should be
%lld\n. Related: try this with your version:
expr 42949673000 : '.*'
Your diff will have that return 2, when the correct answer is 11: the
format string in the asprintf() call in to_string() needs to be
updated:
- if (asprintf(tmp, %d, vp-u.i) == -1)
+ if (asprintf(tmp, %lld, vp-u.i) == -1)
Philip Guenther
Re: expr(1) diff 2 of 3, make it able to accept c-style radix prefixes in integers
On Fri, Jan 14, 2011 at 8:11 PM, Benny Lofgren bl-li...@lofgren.biz wrote: + Makes it able to use C-style radix prefixes to integers in order to do calculations in octal and hexadecimal. In the olden days, early '80:s to be specific, I worked at a company that produced a unix flavour called D-NIX, which had this neat feature in its expr(1). It makes it a breeze to make quick radix conversions, for example. And I guess the habit stuck with me, for to this day it frustrates me not to be able to use expr for that. :-) I hope others find it useful too. For example: skynet:/usr/src/bin/expr# expr 0x1 + 15 131086 skynet:/usr/src/bin/expr# - Hexadecimal numbers (starting with 0x or 0X) is no longer recognized as strings. (The common construct expr 'X'$FOO = 'X' would still work as expected, of course.) Probably not a big concern. - POSIX? Unfortunately, this would make expr violate POSIX. 0x0 must be treated as a (non-empty) string and not as integer zero. So, for example: expr 0x0 '|' foo must return '0x0' and expr 0x34 must return '0x34'. Similarly: expr 030 '|' foo must return '30'. So, what's the answer for someone wanting to do base conversion? If they use sh/ksh, then the answer is $((...)): $ echo $((0x20)) 32 $ csh shmucks^Wusers can use bc or dc for arbitrary base conversion: % printf 'ibase=16\n%s\n' 20 | bc 32 % echo 16i20p | dc 32 % ...or defer to sh: % sh -c 'echo $((0x20))' 32 % + /* In case there is only one operand, make sure it is validated +* as an integer as well, in case we for example want to print it +* in a different radix. +*/ + (void) to_integer(tokval); Ahem: $ obj/expr Segmentation fault (core dumped) $ Philip Guenther
Re: Make expr(1) 64-bit capable and radix-aware
On Fri, Jan 14, 2011 at 08:22:25PM -0700, Theo de Raadt wrote: + Makes it 64-bit capable on 64-bit architectures by changing relevant int:s to long:s. I think this is a problem. I would expect a unix utility of this importance to work exactly the same on all our platforms. Additionally, i very much prefer to have as little as possible differecnes between expr(1) and the ksh builtin. -Otto
Re: expr(1) diff 3 of 3, make it able to print result in different radixes
On Fri, Jan 14, 2011 at 8:13 PM, Benny Lofgren bl-li...@lofgren.biz wrote: + Makes it able to output calculation results in hex and octal. This is of course the reverse functionality to the previous. Works like this: ... - And of course POSIX, this everlasting spectre? No problems from POSIX on this. Philip Guenther
Re: expr(1) diff 2 of 3, make it able to accept c-style radix prefixes in integers
On Fri, Jan 14, 2011 at 10:39 PM, Philip Guenther guent...@gmail.com wrote: On Fri, Jan 14, 2011 at 8:11 PM, Benny Lofgren bl-li...@lofgren.biz wrote: + Makes it able to use C-style radix prefixes to integers in order to do calculations in octal and hexadecimal. ... Unfortunately, this would make expr violate POSIX. I should note that this would be legal behavior if a non-POSIX option was used. For example, it would be legal to behave like this if any of your proposed -c, -o, -x, or -X options were used. Philip Guenther
Multiplique sus clientes
This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. [demime 1.01d removed an attachment of type image/png which had a name of technorati_32.png] [demime 1.01d removed an attachment of type image/png which had a name of delicious_32.png] [demime 1.01d removed an attachment of type image/png which had a name of linkedin_32.png] [demime 1.01d removed an attachment of type image/png which had a name of blogger_32.png] [demime 1.01d removed an attachment of type image/png which had a name of facebook_32.png] [demime 1.01d removed an attachment of type image/png which had a name of twitter_32.png] [demime 1.01d removed an attachment of type image/png which had a name of myspace_32.png]
