Linux-Development-Sys Digest #981, Volume #6 Wed, 21 Jul 99 20:14:02 EDT
Contents:
Re: Why not C++ (Kaz Kylheku)
scsi ioctl send command? (eric thompson)
Re: scsi ioctl send command? (Jerry Peters)
Linux on Intel 810 chipset - multimedia support? (Wolfgang Denk)
Re: basic_string on Linux using SMP - bug? (Kaz Kylheku)
1394 Support on Linux ("Lon Canaday")
Re: scsi ioctl send command? (Lawrence F Barnes)
running a large, busy linux box (Mr Happy)
Re: MICROSOFT LINUX DISTRIBUTION (Bill Anderson)
Re: Problem getting the printers working, help? (Chris Mahmood)
RedHat 6.0 support for SB AWE64. Netscape, too ([EMAIL PROTECTED])
Re: basic_string on Linux using SMP - bug? ("Paul Archard")
building JWS1.1.3 Major Problems. (Matt)
Re: when will Linux support > 2GB file size??? (Jonathan A. Buzzard)
Re: when will Linux support > 2GB file size??? (Warren Young)
Re: when will Linux support > 2GB file size??? (Warren Young)
Re: Help - Need to shift memeory over to /var ASAP. (Norman Levin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Wed, 21 Jul 1999 20:52:26 GMT
On Wed, 21 Jul 1999 12:24:12 -0700, David Schwartz <[EMAIL PROTECTED]> wrote:
>
>Kaz Kylheku wrote:
>>
>> On Tue, 20 Jul 1999 20:40:52 -0700, David Schwartz <[EMAIL PROTECTED]> wrote:
>> > Sometimes the rules do need to be broken for one reason or another. A
>> >good language lets you do that when you need to.
>>
>> An even better language lets you do it whenever you have the slightest
>> urge. E.g. C and C++. :)
>
> It is not the language's place to decide when you need to break the
>rules. That's your job.
Except when, like millions of C and C++ programmers, you don't know the better
portion of the rules, so that you don't know that you are breaking them.
Constructs along the schema of
a[i] = i++;
can often be unearthed in production code. Because of the possibility of
writing ambiguous expressions that do not violate any syntax rule or
constraint, even an experienced programmer can unintentionally break the rules.
------------------------------
From: eric thompson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: scsi ioctl send command?
Date: Wed, 21 Jul 1999 16:21:03 -0400
Reply-To: [EMAIL PROTECTED]
Hi-
how can one do something like the following: (from aix)
struct my_sc_iocmd scmd;
//struct sctl_io scmd;
int return_code;
memset((void *) &scmd, 0, sizeof(scmd));
scmd.flags = RdWr;
scmd.command_length = cdblen;
memcpy(scmd.scsi_cdb, cdb, cdblen);
scmd.buffer = buf;
scmd.data_length = buflen;
scmd.timeout_value = 1000;
return_code = ioctl(tap_fd, STIOCMD, &scmd);
I am wondering what the equivalent is to STIOCMD. this is for a scsi
tape device. there is none equivalent in mtio.h nor scsi.h. I do not
want the MTOP command for mag tap operation. I am looking for something
to send generic scsi commands like mode sense, log sense, log select,
etc.
I am running 2.2.10 and the tape drive works great, in general...
-thanks
eric
please reply via email if possible.
------------------------------
From: Jerry Peters <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: scsi ioctl send command?
Date: 21 Jul 1999 21:18:06 GMT
Take a look at scsiinfo originally by Eric Youngdale, sorry don't know where to
get it from.
Jerry
In comp.os.linux.development.system eric thompson <[EMAIL PROTECTED]> wrote:
> Hi-
> how can one do something like the following: (from aix)
> struct my_sc_iocmd scmd;
> //struct sctl_io scmd;
> int return_code;
> memset((void *) &scmd, 0, sizeof(scmd));
> scmd.flags = RdWr;
> scmd.command_length = cdblen;
> memcpy(scmd.scsi_cdb, cdb, cdblen);
> scmd.buffer = buf;
> scmd.data_length = buflen;
> scmd.timeout_value = 1000;
> return_code = ioctl(tap_fd, STIOCMD, &scmd);
> I am wondering what the equivalent is to STIOCMD. this is for a scsi
> tape device. there is none equivalent in mtio.h nor scsi.h. I do not
> want the MTOP command for mag tap operation. I am looking for something
> to send generic scsi commands like mode sense, log sense, log select,
> etc.
> I am running 2.2.10 and the tape drive works great, in general...
> -thanks
> eric
> please reply via email if possible.
------------------------------
Crossposted-To: comp.os.linux.hardware
From: Wolfgang Denk <[EMAIL PROTECTED]>
Subject: Linux on Intel 810 chipset - multimedia support?
Date: Wed, 21 Jul 1999 19:40:27 GMT
Hi,
the Intel 810 chipset seems very interesting for multimedia
applications. How well is this chipset supported by Linux?
I guess the audio part should be no problem (being SB compatible) -
right?
What about the video decoder? Is this working under Linux?
Is somebody working on it?
Thanks in advance,
Wolfgang Denk
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: basic_string on Linux using SMP - bug?
Date: Wed, 21 Jul 1999 20:43:24 GMT
On Wed, 21 Jul 1999 18:42:57 GMT, Paul Archard <[EMAIL PROTECTED]> wrote:
>
>Kaz Kylheku <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Yes. Take a look at the declaration of the Rep member of basic_string<>.
>It's
>> static. The class is not thread-safe, because multiple instances share
>this
>> static object, and there is no lock. (I happen to be looking at the
>version of
>> bastring.cc that came with egcs-1.1b).
>
>Two comments on this,
>
>Firstly, it seems like the static nilRep member is only ever read from, and
>not written to - being the default empty string this would make sense.
>Therefore it would appear that no locking should be necessary.
The initializer for the object specifies a ``false'' for member selfish.
In this case, the method ``grab'' invoked on the static shared null
string simply ups the reference count rather than returning a
newly created object.
The updating of the reference count is far from thread safe. It just uses
the pre-increment. Even if these happens to translate to using the INC and DEC
x86 instructions, it's not safe under SMP, because you need a LOCk prefix.
This means that reference counted copies are done.
Look at the clone() method in the class. It performs an unsafe
increment: ++ref.
It's possible that the ref count does not balance, and a premature
delete takes place, which causes ``delete this'' to be invoked on
the static object. Disaster.
This would tend to explain why you were able to get the program to work by
enabling selfish. It also potentially explains why everything worked
on a single processor---perhaps the ++ref and --ref translate to
INC and DEC instructions which are atomic on single processor x86.
>Secondly, according to the standard, I believe that the stdc++ library is
>supposed to be thread safe for creation of objects. What these objects are
>used for after creation is at the discression (and peril) of the caller, but
>if it is necessary for the caller to provide mutually exclusive creation of
>all strings in a program that would be rather ridiculous (IMHO).
Dunno. From what I recall of the Nov 1996 draft, it doesn't make any provisions
for threading. I could check again, I have hardcopy laying around here
somewhere. :)
------------------------------
From: "Lon Canaday" <[EMAIL PROTECTED]>
Subject: 1394 Support on Linux
Date: Wed, 21 Jul 1999 14:45:06 -0700
Hi,
Does anybody know if the current (or any planned future) kernel supports
IEEE 1394 (Firewire)?
Thanks,
Lon
------------------------------
From: [EMAIL PROTECTED] (Lawrence F Barnes)
Subject: Re: scsi ioctl send command?
Date: Wed, 21 Jul 1999 21:57:30 GMT
On Wed, 21 Jul 1999 16:21:03 -0400, eric thompson
<[EMAIL PROTECTED]> wrote:
>I am wondering what the equivalent is to STIOCMD. this is for a scsi
>tape device. there is none equivalent in mtio.h nor scsi.h. I do not
>want the MTOP command for mag tap operation. I am looking for something
>to send generic scsi commands like mode sense, log sense, log select,
>etc.
>
>I am running 2.2.10 and the tape drive works great, in general...
> -thanks
> eric
>please reply via email if possible.
I replied to this via email as the code is fairly long and I am not
sure its particularly useful to most people. I you want an example of
how to do the above mail me. The example does not have many comments
and makes calls to a common interface library but if you know SCSIi it
should be straight forward to implement it in your own application.
Lawrence F Barnes.
------------------------------
From: [EMAIL PROTECTED] (Mr Happy)
Subject: running a large, busy linux box
Date: 21 Jul 1999 21:45:42 GMT
Hi.
We're running a largish RH 6.0 site. 512meg ram, dual PII 400 box.
I moved our user base to this release from a dusty old slakware
release that was getting "out of pty" errors. I figured the
unix98 pty stuff would fix it, so I built my kernel with 1024
unix98 pty's. So far so good...
There's a few other things we had to tweak to make this work for "many" users.
The best resource (so far) for large linux issues is
the Linux Scalability Project:
http://www.citi.umich.edu/projects/citi-netscape/
I recommend the hash patch. I'm running it on 2.2.10--their current
version isn't a clean patch for that kernel rev but it gets the good parts.
There's a couple other things needed to support 100's of users on
our box. I have the following in rc.local:
#
# this fixes VFS: file-max limit 4096 reached
echo 16384 > /proc/sys/fs/file-max
#
# also need more inodes
echo 65536 > /proc/sys/fs/inode-max
Once you have these in place, the next point of "failure" seems to
be in /usr/src/linux/include/linux/tasks.h:
#define NR_TASKS 512
This is too low--another of the patches from the Scalability site
bumps this to 4000.
I hope that this info helps others run a large user Linux box.
If anyone knows what other issues would arise when running a
large, busy linux box I'd appreciate an email.
Thanks and good luck.
../Steven
[EMAIL PROTECTED]
remove the obvious part to email me :)
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: Wed, 21 Jul 1999 15:45:08 -0600
Bill Anderson wrote:
>
> PeterKeane wrote:
> >
> > >The LDC should then put
> > >some effort into a _Windows_ program that; determines all hardware on the
> > >user's system, sets up an RH kickstart (or similar) install using that
> > >knowledge, and walks the user through repartitioning the drive, followed by
> > >the FTP install.
> >
> > Sounds a lot like the Linux equivalent of
> > InstallShield(tm). I think, thought, that
> > Unix guru's are too tied to their shell
> > scripts to do anything as comprehensible
> > as a simple install program. Besides how
> > are you going to tear them away from
> > their papers on AI long enough to code
> > drivers for winmodems which would turn
> > them into Linmodems and allow this
> > FTP install. :-)
>
> Kickstart is for installing the OS itsself.
errr, I meant to say distribution ...
--
Bill Anderson Linux Administrator
MCS-Boise (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: Chris Mahmood <[EMAIL PROTECTED]>
Subject: Re: Problem getting the printers working, help?
Date: 21 Jul 1999 13:30:04 -0700
this is not the approp. group for this question, but read lp(1),
lpr(1), and possibly printcap(5).
-ckm
------------------------------
From: [EMAIL PROTECTED]
Subject: RedHat 6.0 support for SB AWE64. Netscape, too
Date: 21 Jul 1999 15:56:41 -0700
I upgraded from Slackware 3.x to RedHat 6.0 because of glibc-2.1 and
Gnome. Although RedHat advertises "autodetection and configuration of
hardware" right on the box, I still had to set up isapnp by hand. Now
comes the module loading problem...
On Slackware, I had successfully used the following in my
/etc/conf.modules (by successful, I mean that I never had to think
about the sound modules, since everything loaded as needed):
alias sound sb
alias midi awe_wave
post-install sb modprobe "-k" "adlib_card"
post-install adlib_card modprobe "-k" "awe_wave"
post-install awe_wave /bin/sfxload /usr/local/lib/sfbank/synthgm.sbk
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
options adlib_card io=0x388
However, this contortion causes /etc/rc.d/init.d/sound to barf up the
following upon booting:
Loading sound module
sound: Device or resource busy
Of course, commenting out the autoloading stuff from conf.modules,
rebooting, and typing the following incantation as root works as
advertised:
insmod uart401
insmod sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
insmod awe_wave
sfxload synthgm
However, I don't want to look forward to having to remember to type
the latter after every reboot. So, what did I screw up in my
conf.modules (besides the fact that the adlib_card module in
2.2.5-22smp has unresolved symbols)? Why did RedHat 6.0 think the
device was busy?
Also, is there a way to get Netscape to play embedded midi files using
just the tools that ship with RedHat 6.0?
I visited http://bahamut.mm.t.u-tokyo.ac.jp/~iwai/awedrv/ and
discerned that RedHat 6.0 doesn't come with drvmidi. Instead, it uses
playmidi. Now, playmidi -e works fine. However, I don't know how to
configure Netscape to use playmidi -e to play embedded midi files on
web pages. Netscape seems to insist on using a plug-in and suggested
I download and install the UMP plugin, but I don't need midi emulation
via a .wav file when I have a midi-capable card. I tried midiplg,
also from the web site, but it seems intent on feeding the midi file
to drvmidi via the undocumented "pipe" interface.
I don't have a clue as to what "the right thing to do" here is,
exactly. It is difficult to intuit what the RedHat developers
intended by way of AWE32/64 support.
Advice? Clues? I'm all ears!
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My PGP fingerprint: 15 6E C7 91 5F AF 17 C4 24 93 CB 6B EB 38 B5 E5
------------------------------
From: "Paul Archard" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: basic_string on Linux using SMP - bug?
Date: Wed, 21 Jul 1999 22:33:18 GMT
Thank you for a detailed and enlightening response. My assertion that the
standard dictates thread safety for creation is actually not correct - i was
remembering documentation from SGI that talked about the thread safety in
their implementation (the basis of the one used by egcs). Your explanation
for the behaviour on SMP vs. single processor sounds right on the money and
finally explains the major point that was concerning me. I'm going to try
adding a mutex around that ref count and see if it solves the problem.
Regards,
Paul Archard
Kaz Kylheku <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 21 Jul 1999 18:42:57 GMT, Paul Archard <[EMAIL PROTECTED]> wrote:
> >
> >Kaz Kylheku <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Yes. Take a look at the declaration of the Rep member of
basic_string<>.
> >It's
> >> static. The class is not thread-safe, because multiple instances share
> >this
> >> static object, and there is no lock. (I happen to be looking at the
> >version of
> >> bastring.cc that came with egcs-1.1b).
> >
> >Two comments on this,
> >
> >Firstly, it seems like the static nilRep member is only ever read from,
and
> >not written to - being the default empty string this would make sense.
> >Therefore it would appear that no locking should be necessary.
>
> The initializer for the object specifies a ``false'' for member selfish.
>
> In this case, the method ``grab'' invoked on the static shared null
> string simply ups the reference count rather than returning a
> newly created object.
>
> The updating of the reference count is far from thread safe. It just uses
> the pre-increment. Even if these happens to translate to using the INC and
DEC
> x86 instructions, it's not safe under SMP, because you need a LOCk prefix.
>
> This means that reference counted copies are done.
> Look at the clone() method in the class. It performs an unsafe
> increment: ++ref.
>
> It's possible that the ref count does not balance, and a premature
> delete takes place, which causes ``delete this'' to be invoked on
> the static object. Disaster.
>
> This would tend to explain why you were able to get the program to work by
> enabling selfish. It also potentially explains why everything worked
> on a single processor---perhaps the ++ref and --ref translate to
> INC and DEC instructions which are atomic on single processor x86.
>
> >Secondly, according to the standard, I believe that the stdc++ library is
> >supposed to be thread safe for creation of objects. What these objects
are
> >used for after creation is at the discression (and peril) of the caller,
but
> >if it is necessary for the caller to provide mutually exclusive creation
of
> >all strings in a program that would be rather ridiculous (IMHO).
>
> Dunno. From what I recall of the Nov 1996 draft, it doesn't make any
provisions
> for threading. I could check again, I have hardcopy laying around here
> somewhere. :)
------------------------------
From: Matt <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.programmer,comp.lang.java.machine,comp.os.linux.development.apps,comp.lang.c
Subject: building JWS1.1.3 Major Problems.
Date: Wed, 21 Jul 1999 23:18:41 +0100
Hi,
I am having some major problems compiling and lniking the
javawebserver 1.1.3 in linux SuSE6.1 (glib2.0.7)
All seems to be going well however when the libserver.so
file is being created the 'make' fails.
Does anyone know why and how I can correct it please ?
Many thanks
Matt
bash-2.02# cc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
gcc version 2.7.2.3
make -fd jws_inst.mk install
[snip]....
Finished dependencies of target file
`genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
Dependency
`genunix/com_sun_server_realm_unix_UNIXUserEnumeration.c' is older than
dependent
`genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
No need to remake target
`genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
Finished dependencies of target file `genunix/unknown/libserver.so'.
Must remake target `genunix/unknown/libserver.so'.
cc -shared -fPIC -Igenunix -I/usr/lib/jdk1.1.7/include
-I/usr/lib/jdk1.1.7/include/genunix -o genunix/unknown/libserver.so
genunix/unknown/server.o genunix/unknown/UNIXUser.o
genunix/unknown/UNIXUserEnumeration.o
genunix/unknown/com_sun_server_ServerProcess.o
genunix/unknown/com_sun_server_realm_unix_UNIXUser.o
genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o
Putting child 0x0806f210 PID 00857 on the chain.
Live child 0x0806f210 PID 857
genunix/unknown/com_sun_server_realm_unix_UNIXUser.o: In function
`com_sun_server_realm_unix_UNIXUser_loadFromPasswd':
genunix/unknown/com_sun_server_realm_unix_UNIXUser.o(.text+0x0):
multiple definition of
`com_sun_server_realm_unix_UNIXUser_loadFromPasswd'
genunix/unknown/UNIXUser.o(.text+0x0): first defined here
genunix/unknown/com_sun_server_realm_unix_UNIXUser.o: In function
`com_sun_server_realm_unix_UNIXUser_checkCrypt':
genunix/unknown/com_sun_server_realm_unix_UNIXUser.o(.text+0xd0):
multiple definition of `com_sun_server_realm_unix_UNIXUser_checkCrypt'
genunix/unknown/UNIXUser.o(.text+0xd0): first defined here
genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o: In
function `com_sun_server_realm_unix_UNIXUserEnumeration_setpwent':
genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o(.text+0x0):
multiple definition of
`com_sun_server_realm_unix_UNIXUserEnumeration_setpwent'
genunix/unknown/UNIXUserEnumeration.o(.text+0x0): first defined here
genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o: In
function
`com_sun_server_realm_unix_UNIXUserEnumeration_getNextUserName':
genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o(.text+0x20):
multiple definition of
`com_sun_server_realm_unix_UNIXUserEnumeration_getNextUserName'
genunix/unknown/UNIXUserEnumeration.o(.text+0x20): first defined here
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x0806f210 PID 857
make: *** [genunix/unknown/libserver.so] Error 1
Removing child 0x0806f210 PID 857 from chain.
My make file..
###################################################
# @(#)Makefile.sol 1.11 97/11/06
#
# Solaris-specific makefile for building optional native library
support.
# Use this as a starting point for porting to other UNIX platforms.
#
# Path to top of Java Web Server distribution tree
TOP = ..
# Name of the library we're making (given to System.loadLibrary)
LIBNAME = server
# Location of Java Developer's Kit (and runtime)
JAVA_HOME=/usr/lib/jdk1.1.7
# Java runtime flags
JAVAH=$(JAVA_HOME)/bin/javah
CLASSPATH=$(TOP)/classes:$(TOP)/lib/classes.zip:$(JAVA_HOME)/classes:$(JAVA_HOME)/lib/classes.zip
# OS and machine type
OS = genunix
ARCH = unknown
OBJ = $(OS)/$(ARCH)
# Preprocessor, compiler, linker, and related flags
CC = cc
CFLAGS = -shared -fPIC
CPPFLAGS = -I$(OS) -I$(JAVA_HOME)/include
-I$(JAVA_HOME)/include/$(OS)
LDFLAGS = #-G -h $(LIBNAME)
INSTALL = /usr/bin/install
LIBDIR = $(TOP)/lib/$(OBJ)
LIBRARY = $(OBJ)/lib$(LIBNAME).so
OBJS = $(OBJ)/server.o \
$(OBJ)/UNIXUser.o \
$(OBJ)/UNIXUserEnumeration.o \
$(OBJ)/com_sun_server_ServerProcess.o \
$(OBJ)/com_sun_server_realm_unix_UNIXUser.o \
$(OBJ)/com_sun_server_realm_unix_UNIXUserEnumeration.o
default all: $(LIBRARY)
$(LIBRARY): $(OBJS)
$(LINK.c) -o $@ $(OBJS)
$(OBJ)/server.o: server.c $(OS)/com_sun_server_ServerProcess.h
$(COMPILE.c) -o $@ server.c
$(OBJ)/UNIXUser.o: UNIXUser.c $(OS)/com_sun_server_realm_unix_UNIXUser.h
$(COMPILE.c) -o $@ UNIXUser.c
$(OBJ)/UNIXUserEnumeration.o: UNIXUserEnumeration.c \
$(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.h
$(COMPILE.c) -o $@ UNIXUserEnumeration.c
$(OBJ)/com_sun_server_ServerProcess.o:
$(OS)/com_sun_server_ServerProcess.c
$(COMPILE.c) -o $@ $(OS)/com_sun_server_ServerProcess.c
$(OS)/com_sun_server_ServerProcess.c:
$(JAVAH) -d $(OS) -classpath $(CLASSPATH) -stubs
com.sun.server.ServerProcess
$(OS)/com_sun_server_ServerProcess.h:
$(JAVAH) -d $(OS) -classpath $(CLASSPATH)
com.sun.server.ServerProcess
$(OBJ)/com_sun_server_realm_unix_UNIXUser.o:
$(OS)/com_sun_server_realm_unix_UNIXUser.c
$(COMPILE.c) -o $@ $(OS)/com_sun_server_realm_unix_UNIXUser.c
$(OS)/com_sun_server_realm_unix_UNIXUser.c:
$(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
-stubs com.sun.server.realm.unix.UNIXUser
$(OS)/com_sun_server_realm_unix_UNIXUser.h:
$(JAVAH) -d $(OS) -classpath $(CLASSPATH)
com.sun.server.realm.unix.UNIXUser
$(OBJ)/com_sun_server_realm_unix_UNIXUserEnumeration.o: \
$(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c
$(COMPILE.c) -o $@
$(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c
$(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c:
$(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
-stubs com.sun.server.realm.unix.UNIXUserEnumeration
$(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.h:
$(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
com.sun.server.realm.unix.UNIXUserEnumeration
install: $(LIBRARY)
$(INSTALL) -d $(LIBDIR)
$(INSTALL) -c $(LIBRARY) $(LIBDIR)
clean:
rm -rf $(OS)
.INIT:
-@mkdir -p $(OBJ)
.KEEP_STATE:
------------------------------
From: [EMAIL PROTECTED] (Jonathan A. Buzzard)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: Thu, 22 Jul 1999 00:00:21 +0100
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Christopher B. Browne) writes:
[SNIP]
>
> There are effectively three choices:
> a) Leave it alone, letting 32 bit systems have 32 bit limitations, and
> 64 bit systems have 64 bit limits, which is the situation we have at
> present,
>
> b) Move to 64 bit representations on all platforms, which results in a
> performance "hit" for 32 bit systems, but which has the positive effect
> that it is a "linear" change, or
>
> c) Segment things, having the *option* of using a 64 bit API when
> desired, and a 32/64 bit API (platform-dependent) when you "don't care."
>
> My suspicion is that the best way to handle this is to go with option a)
> for the time being, and then move to b) in about five years when 64 bit
> processors become dominant in the marketplace.
Belive you me option a) is not a realsitic option. Far too many people
have a requirement to handle files larger than 2GB *today* on a 32bit
system.
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: Wed, 21 Jul 1999 17:47:07 -0600
"Christopher B. Browne" wrote:
>
> b) Move to 64 bit representations on all platforms, which results in a
> performance "hit" for 32 bit systems, but which has the positive effect
> that it is a "linear" change, or
This will require recompiling everything, I believe -- it breaks the
kernel-to-user-mode ABI. Let's not take this option if we don't have
to.
> c) Segment things, having the *option* of using a 64 bit API when
> desired, and a 32/64 bit API (platform-dependent) when you "don't care."
This option may sound nasty, but it has enjoyed some commercial
success. In at least some ways, the real competition for Linux isn't
NT, but higher-end Unix-on-Intel operating systems like UnixWare. UW
isn't pretty, but it at least doesn't have the 2GB memory and file size
limitations.
It gets past the first via the P6 architecture's PAE (processor address
extensions) to the tune of 64 GB. I understand that Linux won't be
supporting this, but it's interesting to note. By this feature,
UnixWare is able to address 8 GB linearly, plus up to 64 GB via special
shared memory APIs, which big-database vendors like Oracle use.
UnixWare gets past the file limits simply by having a better filesystem:
Vertias' vxfs. (1TB filesystems and 1TB files within those
filesystems.)
If you're interested in further details on the differences, see my *ix
pages, linked below. I'm a Linux fan myself, but I thought it would be
worthwhile to compare my preferred OS to the Unix I find myself actually
_using_ more, since that's what's installed here at work. After several
revisions due to stirring up the UW crowd, I think it's pretty accurate
and objective.
--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: Wed, 21 Jul 1999 17:50:45 -0600
Peter Samuelson wrote:
>
> I *think* it's an orthogonal problem. sct is reportedly implementing
> vm changes to make use the P6's 36-bit addressing; he and Linus
> apparently worked out the design already. I don't know if that design
> allows userspace to be bigger or if it just does buffering.
I understood from the Linux kernel mailing list FAQ that this feature
was considered too bletcherous to use. Are they serious about putting
it into the standard kernel, or are they just farting around with
oddball hardware features?
UnixWare uses this feature to get up to 8 GB of linearly-addressable
memory, and the remaining 56 GB addressable with 36 bits is available
through extended shared-memory APIs.
--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
Date: Sun, 18 Jul 1999 10:33:41 -0500
From: Norman Levin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Help - Need to shift memeory over to /var ASAP.
You could create a /spool directory in the root filesystem (I'm guessing that
you over compensated for space somewhere and it might be in root.)
Then, use pax to transfer all the data from /var/spool to /spool
Something like:
pax -rw /var/spool /spool
Next - blow away everything under /var/spool since it is in spool
Create a symbolic link - double check this:
ln -s /var/spool /spool
and this might hold you for a while.
--
Norman Levin
vm/dynAmIX inc.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
