Re: FreeBSD Support of Hot Swappable NICs
Wes Peters wrote: Mike Smith wrote: Actually, there's still a *lot* of work that has to be done to make this work "right" - let me say two things only: "resource allocation" "interrupt routing" And that's just the start. When it comes to network interfaces, trying to unthread them from the system in a small, fixed amount of time like will be required for hot-eject on CPCI, CardBus, etc., is really fugly. Maybe it can be solved in two steps: 1. When the card is physically removed inform the driver that it should shut down and don't try to get to the card afterwards. That means it would handle some subset of configuration requests and delay or throw away any data transfer requests. 2. Later take any neccessary amount of time to clean up the things. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
Doug Rabson wrote: On Thu, 1 Jun 2000, Jordan K. Hubbard wrote: Does this mean we won't get the SMP stuff done next week? I'm back on the 15th (you gain 10 hours coming back) and the SMP meeting isn't until the 16th and 17th. Of course it will. :) So you are running this right before Usenix? Thats annoying - I've already booked a flight to San Diego on the 17th. Meeting *at* Usenix would be good though. By the way, is any FreeBSD event planned for Usenix ? I would be interested in meeting/looking at all the giants of FreeBSD thought :-) -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating a system to boot 4 different OS types.
"Gary T. Corcoran" wrote: Sergey Babkin wrote: The partition number does not really matter, what really matters is that Windows wants to be in the very first tracks of the disk. This is legacy left from DOS which always had the same mania. While this may have once been true, I don't believe it holds for modern versions of Windows. That is, at least for Win98 and Win2000. Whether the kluge known as Windows NT (4) still has that requirement I don't know. In any event, unless you have a specific requirement to use It does. More interesting, if asked to be installed in non-first partition it still silently installs itself in the geometrically first partition on the disk (and then don't boot because it sets up its boot loader to boot from the partition it was asked too). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD kernel as a replacement for Linux kernel
James Howard wrote: Since I mention it, does anyone know the major differences between SCO's new SVR5 (Unixware 7) and traditional SVR4 implementations? Going to SCO's website all I get is market-speak. As I've been told it was named SVR5 to mark inclusion of enterprise-level features (and yes, for marketing reasons): - better CPU scalability with modular support for different platforms (initially UW7 was up to 8 CPUs well and 12 CPUs so-so, now up to 16 CPUs well) - support for over 4GB of memory - support for large areas of shared memory attached to great many processes - multi-path I/O support (a disk can be connected to 2 or more SCSI buses) - integrated volume manager (from Veritas, terrible thing, and often broken) - hot-swappable disks - hot-pluggable PCI cards - high availablilty clustering (Reliant from Veritas, terrible thing, and sometimes broken) Internally it had significant extensions in the multiprocessor support, memory and re-designed I/O subsystem. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: further question to bus_alloc_resource
Alexander Langer wrote: Thus spake Sergey Babkin ([EMAIL PROTECTED]): compiled in the kernel (as opposed to being loaded as a module) then it never gets unloaded. And many drivers were written before the loadable modules appeared. Yes. But what about the others. /sys/dev/aha/aha_mca.c for example - it is part of module (aha), allocs resources, but never releases them. Well, I suppose unloading drivers makes much sense only in case if hardware supports hot-plug. I see the argument of upgrading the driver version without reboot as purely theoretical. For driver debugging the need to chnage the driver commonly happens after the old version somehow wedges the system. And upgrading drivers on a running production system is not something I personally would do. This is a dangerous operation and if it would cause any problems they would better happen at pre-scheduled boot time, not on a running machines with users. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: request for review: bus_alloc_resource(9)
Warner Losh wrote:
In message [EMAIL PROTECTED] Sergey Babkin writes:
: The code seems to guarantee that if the probe routine returns 0
: then the attach routine will be called right away. So if the probe
: routine returns 0 they don't have to be freed. Actually, the
: comments seem to say explicitly that the resources should be
: freed only if the probe routine returns a negative value but not 0.
: Or am I missing something ?
The code doesn't write the guarantee. In general probe routines are
supposed to be idempotent. You are supposed to be able to have them
be called multiple times, at least in theory. The probe routine
should not hold resources past the end of its execution, positive or
negative.
I'm not sure where you found the comments that say that the probe
routine can hold resources after it is called. I couldn't find any.
Sorry that I did not quote it in the first e-mail. In kern/device_if.m:
#
# Probe to see if the device is present. Return 0 if the device exists,
# ENXIO if it cannot be found. If some other error happens during the
# probe (such as a memory allocation failure), an appropriate error code
# should be returned. For cases where more than one driver matches a
# device, a priority value can be returned. In this case, success codes
# are values less than or equal to zero with the highest value representing
# the best match. Failure codes are represented by positive values and
# the regular unix error codes should be used for the purpose.
# If a driver returns a success code which is less than zero, it must
# not assume that it will be the same driver which is attached to the
# device. In particular, it must not assume that any values stored in
# the softc structure will be available for its attach method and any
# resources allocated during probe must be released and re-allocated
# if the attach method is called. If a success code of zero is
# returned, the driver can assume that it will be the one attached.
#
# Devices which implement busses should use this method to probe for
# the existence of devices attached to the bus and add them as
# children. If this is combined with the use of bus_generic_attach,
# the child devices will be automatically probed and attached.
#
METHOD int probe {
device_t dev;
};
It is also legal for buses to probe all their devices before attaching
any of them (the pci bus does this, iirc, so that generic drivers can
handle some hardware and more specific drivers can handle other).
There's nothing that states probe_and_attach is the only way to get
things done.
That comment does not guarantee that attach will be called right
away but I suppose it guarantees that if probe() returns 0 it
may expect that attach() will eventually be called and keep the
resources and contents of its structs softc between probe() and
attach().
Finally, there's a comment in subr_bus:
device_set_driver(child, best-driver);
if (pri 0) {
/*
* A bit bogus. Call the probe method again to make sure
* that we have the right description.
*/
DEVICE_PROBE(child);
}
which indicates to me that the probe routines will be called multiple
times if they return 0 (pri is the priority they returned, 0 meaning
it is mine and nobody else's).
Yes, that's what I said in the first quoted paraghaph: if probe
returns 0 (priority arbitration between multiple drivers in a class)
or 0 (error) then it must free the resources before exit and don't
assume that the contents of struct softc will be presevred between
probe and attach. But if probe returns 0 it may keep the resources.
Also some resources have problems with freeing them: for example,
if a piece of memory was allocated using bus_dmamem_alloc() with
lowaddr of BUS_SPACE_MAXADDR_24BIT then bus_dmamem_free() won't
really free it but just throw it away (I suppose contigfree() did not
exist when it was written). So it's better to keep these resources
between probe and attach if probe returns 0.
-SB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: System management with large groups
Jonathan Laventhol wrote: Dear FreeBSD Hackers -- I've got a technically-straightfordward but nonetheless business-critical problem with the groups structures in FreeBSD which perhaps you kind souls can help me with. We currently use FreeBSD 3.3-RELEASE through 4.0-RELEASE via Walnut Creek CDs for DNS, e-mail, web, ftp, various proxies, tacacs and a number of custom web-delivered databases. There are maybe 15 small FreeBSD machines doing these jobs. Only systems management actually log in on the machines, the real users have NOLOGIN shells. We do not currently use NIS but I'm considering it. last time I did something like this was a few years ago with FreeBSD 2.1 but I hope that my comments may be still useful. I am looking at the technical feasibility of moving to FreeBSD with Samba and Netatalk. Another approach would be to modify Samba and Netatalk to check the permissions for net users by itself, without bringing this burden to OS. *** ISSUES *** The most significant issue is the limits on groups. Part of this is because of the inherent limits of user-group-world masks versus ACLS -- which we can live with and would help us by simpifying the problems -- and part is because of long-legacy limits within 4.4bsd. You may want to look at "poor man's ACLs" http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14584 They are not really ACLs but IMHO are useful. Because of the size and structure of my company a person might need to be in 20 or 30 groups anyway. Because of working around the ACL issue, we'd need to have a large number of groups -- perhaps thousands -- and individual users in large proportion of those. Some users might even be in *every* group. "In every group" in your case means thousands of groups, not 20 to 30. This may be the real problem. *** APPARENT CAUSES *** 1. I see that the 200-users-per-group limit is gone since 3.0-RELEASE. Was there such a limit ? As far as I remember there are limits for the number of groups in each line of /etc/group and number of characters in each line of /etc/group. But there may be multiple lines in /etc/group (that's true for any kind of Unix except possibly Linux) corresponding to a group. For example: somegroup:*:200:user1,user2,user3 somegroup:*:200:user4,user5,user6 So circumventing these limits is easy. 2. I'm concerned about the 1+16 groups-per-user issue You can increase that easily. I think NGROUPS is what you need but I can't remember now exactly. I increased that to something like 50 without any problems. But making it equal to a few thousands may be a problem. Or maybe not. Try and see. Of course, it will cause somewhat higher memory consumption and CPU expenses but it may be not that bad. 3. I'm concerned about large numbers of groups in a flat group(5) file. It may be a bit slow but should not cause any other problems. *** QUESTIONS *** Question 0: Is this a sensible way to solve my access rights issues? Anybody got a better way altogether? (Maybe just hack Samba?) Yes, hacking Samba looks like a good solution. Question 2: What is the relationship between hard-coded NGROUPS and NGROUPS_MAX, and the sysctl kern.ngroups? NGROUPS is defined to be equal to NGROUPS_MAX. Probably kern.ngroups allows to limit the actual maximal number lower than NGROUPS_MAX. Question 3: Can I just edit NGROUPS_MAX somewhere and make it Yes. Probably in /sys/sys/syslimits.h. bigger? Which one do I fix? (Is there a 'make world faq? Never done it before.) I can't say for sure but most probably you don't need to make world. Just rebuild the kernel and that has a good chance to fix it. Maybe you will also need to rebuild Samba. Question 4: What do people think might break? Would it be better, worse, or impossible to do this with NIS? Personally I don't believe in NIS. But NIS may be better in the sense that it uses indexed files instead of /etc/groups, so the searches in them will be fatre. Question 5: Has anybody done anything like a vigr (like vipw) for /etc/group? Our (locally-written) user database would be changing the groups all the time. I think FreeBSD still has no binary indexed file for /etc/group, unlike /etc/master.passwd. So you can just edit /etc/group with vi. It also gives warnings when multiple people try to edit the same file at once. One of the things that I think would be good to implement is the ability to create hierarchies of groups. Say, create a file /etc/metagroups containing: ... group1:*:1000:user1,user2,user3 group2:*:1001:user2,*group1,user4 group3:*:1002:user5,*group2 ... Meaning that group2 also contains all the users from group1 and group3 contains all the users from group2. This file after running some Perl-based or shell-based converter would generate /etc/group containing: ... group1:*:1000:user1,user2,user3 group2:*:1001:user2,user4,user1,user3 group3:*:1002:user5,user2,user4,user1,user3 ... That should be easy enough to
Re: further question to bus_alloc_resource
Alexander Langer wrote: Thus spake Alexander Langer ([EMAIL PROTECTED]): If so, I'm going to write patches. ... for almost every driver in the tree. Hmm. EITHER almost all people never unloaded their driver, or I still understood wide parts wrong. I grepped through /sys now and only 10% of the drivers save the rid. Strange. Enlighten me, please. .-9 If a driver was written with expectation that it will be always compiled in the kernel (as opposed to being loaded as a module) then it never gets unloaded. And many drivers were written before the loadable modules appeared. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: request for review: bus_alloc_resource(9)
Warner Losh wrote: One should generally only call these functions in attach. If you must call them in probe, one must release the resource before returning from the probe. However, since they can affect bridge settings, it may be unavoidable to call them from the probe routine. The code seems to guarantee that if the probe routine returns 0 then the attach routine will be called right away. So if the probe routine returns 0 they don't have to be freed. Actually, the comments seem to say explicitly that the resources should be freed only if the probe routine returns a negative value but not 0. Or am I missing something ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
de-GNUfication of Digiboard driver ?
Hi, I've been reading recently some stories about the licensing issues and that brought me to an interesting conclusion: apparently, we are able to change the license of the Digiboard driver from GPL to BSD ? It does not seem to be that much important any more as these cards are obsolete, but still. I was the original author of that driver. To get the information about the Digi interface I've read the Linux driver. I supposed that it made me mentally contaminated with GPL. But all the FreeBSD driver was written from scratch, with none of the Linux code re-used (except for the array with the image of firmware but apparently that one was available as well from non-GPL-contaminated sources, such as Digi's drivers for other Unixes). But now looking at the BSD-USL case it seems like I was wrong about the mental contamination. Apparently none of the author of the later changes to this driver were enthusiastic about GPL as well. So if I'm getting the things right, can we just go ahead now and change its license to BSD ? Or am I wrong ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can NMI drop a hanging FreeBSD kernel into DDB?
Warner Losh wrote: In message [EMAIL PROTECTED] Sergey Babkin writes: : Seems like most of the modern machines just don't have that : pin on the PCI bus connected anywhere. But on most of them : (though not all) the pin on ISA works. Some high-end machines : like Unisys or Compaq have an NMI button on the box (sometimes : under the cover). IOCHK* isn't on the PCI bus at all. You have to do weird things for it to generate an NMI that I've never quite worked out. I sure wish I Probably SERR# is used instead. We have small cards at work with a big button, ISA connector on one side and PCI connector on the other one. I'm not sure exactly to which signal on the bus is it connected. But the PCI side commonly don't work for the modern machines. could get the pcccard bus (and/or cardbus) to genereate NMIs for laptop hacking at times. If it's derived from PCI you can try to use SERR# or its analog. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can NMI drop a hanging FreeBSD kernel into DDB?
Peter Jeremy wrote: On 2000-May-11 07:10:27 +1000, Wilko Bulte [EMAIL PROTECTED] wrote: And if you force the IOCHK* line on an AT slot to GND? Would that work on modern PCI machines? Grounding IOCHK* does cause an NMI on the only PCI machine I've tried it on. It looks like this is maskable in the Intel PIIX3 (and presumably later) chips, so it may depend on the BIOS. Seems like most of the modern machines just don't have that pin on the PCI bus connected anywhere. But on most of them (though not all) the pin on ISA works. Some high-end machines like Unisys or Compaq have an NMI button on the box (sometimes under the cover). I don't know whether this will still work if the PCI bus is hung. I Most probably it won't. The keyboard is connected on most machines below PCI, so if PCI hangs you won't be able to do anything anyway. The same problem would be in the other direction, for PCI video card. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mouse Sync Problems with KVM
Dragos Ruiu wrote: I'll try asking here now I have a freebsd system(3.4S) on a KVM and every time the monitored system is switched, the mouse driver gets fuxored, and when you switch back to the system the driver starts outputting oodles of the following messages to syslog every time the mouse is moved: ... brands are identical(masterview)... But the KVM works with Wintendo/NT, Linux and OpenBSD just fine... on the same HW. Possibly the problem is with the exact mode of the keyboard/mouse controller. I can give an example: I have a KVM (Connectpro BA-12P, can't remember the name of OEM now) installed with UnixWare machines which mostly works but when I exit from KDB (the UW kernel debugger) the keyboard hangs. Disconnecting and re-connecting the physical keyboard fixes the problem. My guess is that the KVM handles properly only a subset of the commands that may be set to and from the keyboard, so if some unsupported command passes through it all the kinds of weird effects start happening. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0-STABLE?
"Jordan K. Hubbard" wrote: The cvsupit package is now updated to deal with the current branch state of affairs, the cvsup 16.1 upgrade AND it's linked-to properly so that simply: By the way, a stupid question: I've received a 4-CDROM package today, saying 4.0-March 2000. The line on the shipping list says that it's -current. But is not -current 5.0 now, and 4 CDROMs ? So I wonder, is it really -current or -stable ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody have tools to read a Digital Unix vdump tape on FreebSD?
Wilko Bulte wrote: On Wed, Mar 29, 2000 at 03:59:52PM +0200, [EMAIL PROTECTED] wrote: Does anybody know of tools to read a Digital Unix "vdump" tape on FreeBSD? I have a number of such tapes, and would prefer to read them on an (Intel) FreeBSD box instead of having to reinstall DU on a machine which has had its disks wiped. Vdump, the dump incarnation for Tru64 AdvFS, can to the best of my knowledge only be read by vrestore. I'm afraid your stuck to using a T64 box for this. If AdvFS is just another incarnation of VXFS there may be a chance that it could be read by vxrestore on UnixWare. So if there is absolutely no Alpha machine around then free UnixWare (binary-only but still free except for the CD cost, like $17) may be worth a try. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Why StarOffice continuously restarted setup - the answer
Hi, A while ago I tried to install StarOffice and had a problem that every time I tried to start it it went into setup again and again. I've asked about this in -hackers and found that some people had the same problem but nobody has a solution. Well, I've found that solution today and in case anyone else hits that problem, here it is: I'm using the July '99 4.0-SNAPSHOT and in that snapshot reading /proc/NNN/cmdline returns a line with '\n' on the end. StarOffice tried to open a file with that name (its own code) and, of course, failed. Removing that '\n' in procfs fixed the things. One more catch is that the StarOffice bin directory must be in the path, otherwise the same problem follows. Both of these problems seem to be already fixed in -current. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD-boot
Christian Gusenbauer wrote: Hi David! I'm sorry for you, but FBSDBOOT will never support ELF binaries :-(! As developer of this utility I had a discussion about supporting ELF when ELF was introduced into FreeBSD. The reason, why ELF support was not integrated is, that the new boot loader and the kernel rely on the state of the hardware, BIOS and BIOS extensions. Sorry for a stupid question but how was it able to boot with aout ? I think FBSDBOOT never worked after HIMEM.SYS and things like it were loaded, it always required a clear plain DOS to work. So maybe there is a chance that it can be adapted for ELF when started from a plain DOS ? Since booting DOS modifies the lower memory and hardware settings (eg. sets registers, or modifies interrupt vectors) this state will not exist, when you start FBSDBOOT. FBSDBOOT itself *can not* restore this state and therefore fails to start up the ELF binary (loader and/or kernel). How about loading the kernel starting at 1MB and leaving the memory under 1MB unused ? Then you won't even have to restore the interrupt vectors: as long as DOS is left in its place all the interrupts should not get broken. Of course, there is a well known address in the BIOS, where the original interrupt descriptor table is located, but restoring this table is not enough. You also have to re-initialise the various devices (eg. Adaptec Controller). But I wonder why would you have to do that ? I guess this would be needed only after the ASPI driver was loaded. But if it was not then DOS just blindly calls the BIOS. And I guess for the boot code there shoul be no difference whether this is IDE BIOS or Adaptec BIOS. Well, maybe nowadays when the plain DOS is almost completely displaced by Windows 9x maybe future work on FBSDBOOT is not worth the effort in any case. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD as high speed router
Martin Cracauer wrote: In [EMAIL PROTECTED], Christoph Kukulies wrote: Would be interesting to tell how you managed to produce a bootable floppy with the subsequent scripting that starts the OS and all that. The trick I used is that I have a custom `init` binary, which looks at getpid() and argv[0] and depending on that bahaves like: Now as the CD-ROM drives are quite cheap (I've got a 24x IDE drive for $30 about half a year ago) and the CD-writers are commonplace (and the writable/ re-witable CDs are also cheap) a bootable CD-ROM may be a simpler and more extensible solution. The bootable CD-ROMs can be created with mkhybrid: just create a floppy image that will mount cdrom as it root FS and give it to mkhybrid. You can still use floppy for such things as configuration files. The only caveat is to make sure that your BIOS is able to boot from CDROM. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DeCSS
Peter Wemm wrote: I would love to make a port of this, for reasons that become obvious once you see the page. (Think of all the mailing list archives and mirrors) http://www.totse.com/DeCSS/ Be sure to read it before commenting, it's not what you might think. I can't help keeping wondering if this MAA is missing the point completely: why would someone need the decryption to make a _copy_ ? A copy is a copy and it appears to me that the encrypted bits written on the disk surface could be copied just exactly as well as the decrypted bits. Probably the real reason they start this activity is because otherwise they would lose some kind of royalties from the DVD-players manufacturers. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi target mode
Olaf Hoyer wrote: a. settings on the controller card (e.g. scsi id, termination) b. freebsd configuration on the initiator and target PCs. (e.g. do we use scsi_pt.c, scsi_target.c, etc). here's a diagram depicting what we want to do. we're trying to setup a PC (PC2 below) with an adaptec controller to act as an emulated disk. PC 1 will access the disks on PC 2. __ __ | PC1| scsi cable|PC2 scsi bus| | adaptec 2940 | = | adaptec 2940 disk | | SCSI ID=7 | | SCSI ID=0SCSI ID=5 | |__| |__| Hi! Well, I'd rather try (for simplification) following combo: I won't connect the two 2940 directly. What's the problem ? The only trick is to get termination right: enable it at the ends of the bus and disable it in the middle. Otherwise there is nothing special and I use configurations like this (mupti-path I/O and clusters) routinely at work. Also independently of the location of the cards on the bus you may have to disable the Adaptec BIOS to get the machines booted. But getting the Adaptec working as a target device may be quite tough if possible at all because it's firmware mey not be able of that. The card of choice for target applications is Symbios 8xx. Symbios even provides an example of a simple disk simulator for DOS in theis driver developer's kit. The next obstacle is that AFAIK scsi_target.c is not implementation of a target device. It is a pass-through interface for the host to pas sthe commands to any otherwise un-identified SCSI device. Some time ago I've written the target mode code for the Symbios cards, including a simple disk emulator (to the degree that it looked like a disk but did not store anything written to it) and a SCSI extender through FastEthernet. This was my little private enterprise but now as its commercial value is zero I feel ready to give the code. But the last version to which I ported it was early '98 3.0-current, so it would need considerable efforts to be ported to the current -current. And the software is not of production but of more prototype level of quality: it generally works but if errors or unexpected conditions happen they are not handled well. Actually, I'm even willing to port it, clean up and provide a generic target mode API if the FreeBSD core team would agree to commit it to the system. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi target mode
Wilko Bulte wrote: On Tue, Feb 15, 2000 at 04:00:28PM -0600, David Scheidt wrote: Generally speaking 'joining' machines into cluster(like) you want to use differential SCSI buses. Yes. Of course, I think that you want to use differential SCSI for everything. Cableing is much easier, and much less fussy. It costs more though. And consumes a bit more power due to all the external diff xceiver chips. For in-cabinet single-ended or LVD works just fine. http://www.scsipro.com They make the Y-connectors. They also make the retranslators that can increase the maximal length of the cable dramatically (or at least their web site says so - did not try it myself yet). For the good and reasonably priced cables and terminators I can recommend AESP (http://www.aesp.com , http://www.tla-group.com is the reseller I bought from, had quite good experience). Personally I think that Fibre Channel may be a better choice for the clusters because of thinner cables and longer maximal length. Though it's more expensive. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Books
Bill Maniatty wrote: Shanley and Anderson: PCI System Architecture (2nd Ed) ISBN 1-55860-069-8 small rip in paperback cover I teach operating systems, and would like to add a device driver writing component to the curriculum. I could use this one. There was a good (though somewhat obsolete now) book on the Unix device drivers written by Egan and Texeira (if I got the spelling right - can't check now, left a xerocopy of it back in Russia). I've also seen some book on the Linux drivers, it's more modern but seems to be worse than the first one. I've only looked at it in the book store, so this is only an opinion from a fast look. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsiformat
Christoph Kukulies wrote: I have a block on a SCSI disk (Fujitsu M2954S-512 ) which I cannot write to - fsck hangs eternally. Besides from trying the SCSICNTL utility from Adaptec (which I had to boot off of a DOS floppy) is there a way of formatting a drive from being booted under FreeBSD? E.g. by sending a sequence of approriate commands to the scsi bus? Yes, you can send the SCSI format command to the disk. The document describing the SCSI commands probably still can be found at the Symbios ftp site (or ask me, I can send you a copy I made from there - should be about 300K compressed). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
Mike Smith wrote: Writing documentation is a resource-sucking nuisance; supporting outdated documentation even more so. The BSD driver model is sufficiently simple I think that there might be a compromise solution: when someone learns the interface from analysing the code he might as well document his findings in some way for others to read. This would require minor additional effort. I'm going to try this with CAM in a few weeks and see whether this idea is viable. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cool little 100BaseTX switch - they're coming down in price
Matthew Dillon wrote:
I picked up a nifty little D-Link DSS-5+ 5-port 10/100 switch today
CompUSA had a 5-port network kit labeled 'DFE-910' which had the
DSS-5+ and two DFE-530TX+ NIC Cards ('rl' driver), plus cables, for $130.
It appears to operate quite nicely. I can run all 5 ports at
At work I've got experience with 32-port D-Link 10/100 switched
hub. It works fine except that it hangs occasionally (can be
reset by power-cycling). So we don't buy them any more. Also
at my pre-previous employer we had small 8-port 10Mpbs hubs from
D-Link and they had the same problem, so it seems to be a family
problem. With about 20 hubs there was a hang approximately every
other day.
-SB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
Michael Beckmann wrote: On Thu, Oct 28, 1999 at 03:34:53PM -0700, Matthew Dillon wrote: :OK, so I know now that I can have pretty large files in the Terabyte range. :Very nice. But I assume I cannot mmap anything like a 100 GB file ? : :Michael Intel cpu's only have a 4G address space. Your are limited to around a 2G mmap()ing. You can mmap() any portion of a larger file but you cannot mmap() the whole file at once. The easiest thing to do is to simply create a number of fixed-sized files and tell CNFS to use them. Here is the problem: When you want to have 500 GB of storage, you will need 250 files. In the current implementation of nnrpd, this will need 250 file descriptors per nnrpd. This will I think this situation will bring you where you started: you will be able to map a whole one file, but only one file at a time, not 250 files at once. So it would be simpler and more efficient to have only one big file and map the pieces of it as needed. I would also suggest to make these pieces much smaller than 2G: then you will be able to map a number of them at once and when you decide to substitute one mapped piece for another you won't have to re-create the page tables for the whole 2G of the address space. I guess the best size of these pieces depends on the typical request size of your application. limit the number of readers that can be supported on a system, because a nnrpd is spawned for each reader. I was told that nnrpd can be hacked to only consume file descriptors when really needed, but it´s supposed to have a performance penalty. Mapping and unmapping frequently the whole 2G files would impose much higher performance penalty. Also if you plan to have many processes doing mmaps don't forget that each of them would consume some kernel address space for its page tables. With big mmaps you would exhaust your kernel address space very quickly (an example of this is that Oracle on UnixWare uses special calls using 4MB physical pages to map its SGA, otherwise the kernel virtual memory on a large-physical-memory machine gets exhausted very quickly and with terrible consequences). The page tables for such amounts of memory would consume the kernel virtual memory much faster than 250 file descriptors per process. That´s why I´m looking for a way of having large mmap´able files. Are you saying that ALL Intel CPUs, including PIII, can only address 4 GB? I probably need to look at other architectures or solve this fd problem. Pentiums can address more physical memory (again, UnixWare supports up to 16GB of physical memory) - at the price of some performance penalty, but not virtual memory. A 64-bit architecture such as Alpha, UltraSPARC or HP PA-8000 may help you. But I guess what you really need is to split your very big file into a number of pages of some reasonable size and map/unmap them as needed. Although the RISC architectures (at least PA-RISC and RS/6000 but I think the others too) use different organisation of the page tables and for them mapping the big memory areas in many processes should not be a big problem. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
Matthew Dillon wrote: : If you have a genuine need for 500Gig of news spool, : :This is roughly 10 days of newsfeed, btw. This is roughly 20 days of newsfeed if one take the porn, warez, and binaries groups, which contain mostly junk, and try to hold onto them for the full expiration time. If the person setting up the system were to spend a little time filtering out the junk and/or adjusting the expiration it is fairly easy to get away with much smaller spools and an order of magnitude cheaper system. At BEST I wound up using around a 40G spool. If the person isn't willing to filter he pretty much deserves all the pain he creates for himself :-(. Roughly speaking, less then 1% of a typical userbase even bothers to read usenet news. I think if such a high amount of space with such a high number of parallel users is a must then a lot simpler approach would be to divide the news spool (say, by newsgroups) among multiple machines and set up one machine as a kind of proxy, to accept requests from the users and forward them to a machine which really has this particular newsgroup on it. That would also solve the problem with the CPU load and memory size. For further scalability there may be multiple proxy machines and a load balancing appliance of the same kind as the ones used for the web servers. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UFS ACLs
Chuck Youse wrote: I admittedly haven't done much homework on this topic, but I was wondering if anyone has played with the idea of implementing ACLs on top of UFS. One of the weakest areas in UNIX is its lack of fine-grained access control for resources - the biggest resource being, of course, the filesystem. As my personal experience with Novell Netware shows most of the time the presence of the fine-grained access control is a great temptation to create a complete mess in the filesystem. The thing I personally feel neccessary is being able to assign access rights to a file to two separate groups because it's cheap and resolves most of the problems. I have implemented it as a small patch that works with both FFS and EXT2FS in FreeBSD. Let me know if you are interested in looking at it. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Huge Binaries..
Julian Elischer wrote: Has anyone looked at netscape Communicator 4.7 for FreeBSD??? I just installed it. the binary is 13234176 bytes long!! yes folks, that's 13 MB! stripped! With shared libraries! It runs but it's quite easy to make your xserver run out of memory (or something (Sig 11)) One has to wonder what on earth they have in there? (My machine has 32 MB so it can run, but it's a bit of a squeez!) I guess you may need a bigger swap space. A while ago yet with Netscape 3.x and 16MB machine I have found that the smallest acceptable swap size was 50MB or it runs out of memory real quick. Now I my machine has 64MB of memory and 150MB of swap but still Netscape 4.07 occasionally runs out of space. I think it has a big memory leak in the forms code (sometimes it consumes tens of kilobytes per each letter typed) and also big problems with Java support. 4.61 seemed to support Java OK (I was able to run a few games in Java!) but crashed every time I tried to send an e-mail, so I returned back to 4.07. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI disk naming problem
Narvi wrote: See LINT on details of how to wire down scsi devices... Your proposal doesn't take adding a second scsi card into account. UnixWare has a kind od solution for this: when they create the VTOC table (an analog of the BSD disk label) on the disk they have a field in it that contains some piece of random-generated junk that works as a disk ID. The association of the disk number and this ID is also written into resmanager. Resmanager is a thing like sysctl but much more braindamaged and difficult to use, and its contents is saved to disk when the system is stopped. So when the system boots next time it reads in the resmanager database and tries to associate the disks with known ID to the same number which was assigned to them last time. The problem of this method is getting rid of the stale disk ID left in the resmanager, so some way should be provided to do that (and better it be better than in UnixWare). I guess this thing would be rather easy to implement in FreeBSD: instead of the on-disk resmanager database we can use the already existing mechanism of the 3rd stage loader configuration files. And the changes to the SCSI disk driver should be not too complex too. Such a mechanism has also the second (and I suppose the main) use in UnixWare: it is absolutely neccessary for the MultiPath I/O. That is, a disk may be connected to more than one SCSI card and if one of the access paths crashes another one can still be used. There are two problems: first, how do we know that this is the same disk accessible by two paths ? second, if one of the path crashes what are we going to do on the next reboot not to let the disk get re-assigned to another name ? Both of them are resolved by these disk IDs in the VTOCs. -SB On Fri, 1 Oct 1999 [EMAIL PROTECTED] wrote: Current FreeBSD SCSi disk naming mechanism is problem for using more than one disks in the chain during the disk failure. The problem is that the name is not fixed with is SCSI ID. e.g., if one disk is presented in the chain, regardless its SCSI ID, it is always named "da0"; if two disks are installed, the one with lower ID is named da0 and the other will be named as da1. When the lower ID one is crashed, then the other disk will be named as da0 (from da1) after reboot, and it is not mountable due to the name changing. If a system has a UW SCSI controller with 15 disks in the chain, when the first disk (ID = 0) crashed, all rest 14 disks will be useless until either fstab modified or another disk is added with SCSI ID = 0. Why not we use a fixed name corresponding the SCSI ID. That is, disk with ID 0 will be always named as da0, and disk with ID 1 will be always named da1, etc.? Is there problem with fixed disk naming mechanism? -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: return to real mode
Mike Smith wrote: anybody got some reliable, tested, known-good code for getting back to real mode? I'm to the point where I have a working GDT, and paging is turned off, but the last step -- turning off protection enable -- is not working for me. You want to be more explicit about why you want to get back? There are possibly alternatives, or other collateral damage issues that might be worth commenting on. I have an almost-working code written yet in the 2.0.5 days. Then there was a guy Wee Teck [EMAIL PROTECTED] who asked a similar question and I sent my code to him. He has found the final bug and got it working. Maybe he is still on the list and can provide some information. I'm going to send my code and his fix off the list. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wormcontrol write speed
David Scheidt wrote: On Fri, 24 Sep 1999, Sergey Babkin wrote: There is no worm or wormlike support in the SCSI system anymore. Do I need to configure the SCSI target driver for cdrecord or does it just use the CD-ROM driver ? Thank you! It uses either the cd driver, or the passthrough one. I can't remember off hand. (I think it is pass0). Seems like the cd driver should work. I have tried today and it turned out that even for a 2-year-old system wormcontrol does not work any more on the SCSI devices. cdrecord seems to work on either cd or worm driver (which is still here in that 2-years-old system). My old system needed a little patching of physio() to get cdrecord running but this bug seems to be fixed long since then in -current. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StarOffice 5.1 - infinite setup ?
Kevin Day wrote: Hi, I have got a surprising problem with StarOffice 5.1 for Linux on FreeBSD 4.0-current, the latest snapshot. The CD-ROM installation went fine (after I configured the Posix real-time thread support and linked the additional libraries to the Linux compatibility directory and slightly corrected the startup scripts) but when I start the installed program "soffice" it just starts the setup screen again! Tried to Try running staroffice as a non-root user. Tried. Same thing. The only additional problem I noticed about running as root was that it ignores LD_LIBRARY_PATH but I did overcome it by creating symbolic links to the libraries from /usr/compat/linux/lib. Otherwise seems to be no difference (tried also to remove these links and run from an ordinary user: same effect). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StarOffice 5.1 - infinite setup ?
Josef Karthauser wrote: On Wed, Sep 22, 1999 at 08:46:42PM -0500, Kevin Day wrote: Hi, I have got a surprising problem with StarOffice 5.1 for Linux on FreeBSD 4.0-current, the latest snapshot. The CD-ROM installation went fine (after I configured the Posix real-time thread support and linked the additional libraries to the Linux compatibility directory and slightly corrected the startup scripts) but when I start the installed program "soffice" it just starts the setup screen again! Tried to We've got a similar problem. Instals fine as root, runs fine a 'joe', but if anyone else tries to run it they get the setup screen! My hunch is that it's something to do with Seems like I got no suck lucky user :-( permissions on Sys5 IPC queues or something. A Ktrace of both showed that different things were going on, but I lost the plot before working out exactly what. I ran ktrace and truss on it. It seems like it does not use Sys5 IPC at all or at least does not make calls looking like it. It uses an unix-domain socket with long name in /tmp and it seems to work OK (reads and writes through it show up in ktrace). I have even found out why the setup starts: because this clever program calls the setup script. The only question left is why does it do that ? :-( I also have no java support installed. From the message it gave during setup it looked like the java support was optional but not I start thinking whether could it cause this infinite setup. By the way, the exact version I'm trying to install seems to be 5.17, at least all the libraries have *517* in their names. Maybe this also makes some difference. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: StarOffice 5.1 - infinite setup ?
Daniel Eischen wrote: We've got a similar problem. Instals fine as root, runs fine a 'joe', but if anyone else tries to run it they get the setup screen! My hunch is that it's something to do with permissions on Sys5 IPC queues or something. A Ktrace of both showed that different things were going on, but I lost the plot before working out exactly what. I wasn't paying attention to the beginning of this thread, so forgive me if I'm repeating something already stated... Are you sure you initially installed StarOffice with the /net option (./setup /net)? There is also a StarOffice setup file that is No, I did a non-network install. created in the home directory of each person that runs setup (don't recall what the name of it is, .soffice?). You have to be sure to delete this file before running setup. I have checked and the only file was containing the path to the StarOffice directory. Tried to remove it, nothing has changed. Each user then needs to run setup once (without /net) and select a workstation install, which just installs a few files in their home directory. Maybe I'll try a net install next time. Thanks! -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wormcontrol write speed
Soren Schmidt wrote: It seems Luigi Rizzo wrote: Anyhow, I have some changes to the worm stuff, it needs to be dealt with to handle modern HW, and to deal with all the possible block formats thats possible on a CD nowadays. It will probably mean the death of the worm stuff as is now, but I'm the last user anyways so NO! There is me as well Count me as the third one :-) For what ?? -stable ?? I wont touch that one... If its for the old wd driver, it'll ofcause stay around until that is gone too :) Or have I missed something ?? By the way, a stupid question: 4.0-current (at least the latest snapshot) seems to have no worm driver. Is it merged with the cdrom driver now ? Does it still work with the SCSI devices ? In particular, with Philips 3660 ? Thanks! -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
StarOffice 5.1 - infinite setup ?
Hi, I have got a surprising problem with StarOffice 5.1 for Linux on FreeBSD 4.0-current, the latest snapshot. The CD-ROM installation went fine (after I configured the Posix real-time thread support and linked the additional libraries to the Linux compatibility directory and slightly corrected the startup scripts) but when I start the installed program "soffice" it just starts the setup screen again! Tried to go through it, select no additional components, the setup says that everything is installed and exits. I was not able to get anything else from it. Has anyone met this problem before ? Any ideas would be welcome. Thank you! -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD???
Mark Ovens wrote:
On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote:
A funny thing is that Microsoft is porting essentially a
32-bit version of Windows to Merced. All the programs for
Windows that want to use 64-bit support will have to be
modified because the MS compiler defines both int and long
as 32-bit. On the other hand the Unix compilers (at least
UnixWare and as far as I understood that's the common Unix
convention) provide a mode with 64-bit longs that gives
certain degree of 64-bit awareness just by recompiling.
marder-1:/usr/marko{57}% cat size.c
#include stdio.h
int main (void)
{
printf(short == %d\n, sizeof(short));
printf(int == %d\n, sizeof(int));
printf(long == %d\n, sizeof(long));
printf(long long == %d\n, sizeof(long long));
return(0);
}
^D
marder-1:/usr/marko{57}% cc !$
marder-1:/usr/marko{57}% ./a.out
short == 2
int == 4
long == 4
long long == 8
marder-1:/usr/marko{57}%
And the same is true on SunOS 4.1.x as well (although not 100% sure
about long long).
I was talking about compilers for the 64-bit machines. As far
as I understood to make porting easier the major Unix vendors
have agreed on 2 64-bit modes in addition to the compatibility
32-bit mode:
- 32-bit int, 32-bit long, 64-bit long long, 64-bit pointers
- 32-bit int, 64-bit long, 64-bit long long, 64-bit pointers
While the 64-bit Windows NT has 32-bit int, 32-bit long,
64-bit long long, 32-bit pointers, 64-bit some special
kind of pointers.
Although I may be confusing something.
-SB
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD???
Thomas David Rivers wrote: Microsoft needs a "business quality" version of Windows, which it claims is Windows/2000. That version of Windows could benefit from a 64-bit port, if for marketing only; but I don't think it would result in the volume of sales Intel is looking for. A funny thing is that Microsoft is porting essentially a 32-bit version of Windows to Merced. All the programs for Windows that want to use 64-bit support will have to be modified because the MS compiler defines both int and long as 32-bit. On the other hand the Unix compilers (at least UnixWare and as far as I understood that's the common Unix convention) provide a mode with 64-bit longs that gives certain degree of 64-bit awareness just by recompiling. And - let me add - Intel has been down this path before (the i860) - and didn't see the success it wanted (although the i860 is popping up in some interesting places now...) Merced can run the x86 code. Not as fast as the native code but I guess comparable to the Pentiums. I suppose what this "rant" is all about is that I'm not convinced Merced is the "chip of the future" that we all need to be worried about. I'm taking a "wait-and-see" attitude. [Also, since Microsoft has been working closely with Intel regarding Merced for several years now, and has yet to do anything `serious' - I believe they are taking the same "wait-and-see" approach. Likely while telling Intel otherwise.] SCO and IBM with their Monterey-64 project are considering Merced quite seriously. Actually, as far as I know, for Monterey-64 the availability of the Merceds seems to be the limiting factor now. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD??? Intel? - NOT
Jim Bryant wrote: I really don't know how people get started with this. HP has _never_ stated that the chip will handle it; all they have stated is that HPUX applications will continue to be supported. I suggest you people go read comp.arch for a while; there's a fair bit of information cropping up there. For example, there's a wonderful thread going on about HP's previous experience with architecture emulation, including some interesting comments by people at HP. Well, the way I understand things, HP-UX 11 comes in two flavors, 32 bits and 64 bits. I think that 32-bit code is handled in a legacy emulation under 64 bit 11, I'd have to double check that though with the book. PA-8000 (PA-RISC 2.0 architecture) has harware support for the 32-bit (PA-RISC 1.1 architecture) instructions. It's configured by one of the bits in the status register. Alas, HP does not have the PA-RISC 2.0 specs online but they have a whitepaper describing the additions in a nutshell. But I guess internally the system calls are implemented as 64-bit. Speaking about Merced, the same thing is done in SCO/IBM Monterey-64, all the kernel including the implementation of the 32-bit system calls (the UnixWare IA-32 compatibility subsystem) works in the 64-bit mode. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD??? Intel? - NOT
Zuidam, Hans wrote: Hi, The IA64 (merced) is a kind of VLIW (Very Large Instruction Word) processor. It is basically a complete new kind of systems architecture with a i686 (and of course a i586, ..., 4004) slapped on the side. The original processor design was done by HP. See: The IA-64 Architecture at Work, IEEE Computer Vol. 31, No. 7, July 1998 for a more informed description ;-) of the processor. Merced is not VLIW. VLIW means explicit parallelism of instructions, scheduled by the compiler. It also means that the code is tied very closely to the internal CPU architecture and would be incompatible between different CPUs of the same family. I can't remember now how the Merced architecture is named but it's a rudimentary data-flow machine with explicit synchronization points. Intel has an introduction to the Merced architecture on their Web-site. Also there was a talk at the SCO Forum about the Merced assembly language, I guess it should also be available online. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD???
Thomas David Rivers wrote: Microsoft needs a business quality version of Windows, which it claims is Windows/2000. That version of Windows could benefit from a 64-bit port, if for marketing only; but I don't think it would result in the volume of sales Intel is looking for. A funny thing is that Microsoft is porting essentially a 32-bit version of Windows to Merced. All the programs for Windows that want to use 64-bit support will have to be modified because the MS compiler defines both int and long as 32-bit. On the other hand the Unix compilers (at least UnixWare and as far as I understood that's the common Unix convention) provide a mode with 64-bit longs that gives certain degree of 64-bit awareness just by recompiling. And - let me add - Intel has been down this path before (the i860) - and didn't see the success it wanted (although the i860 is popping up in some interesting places now...) Merced can run the x86 code. Not as fast as the native code but I guess comparable to the Pentiums. I suppose what this rant is all about is that I'm not convinced Merced is the chip of the future that we all need to be worried about. I'm taking a wait-and-see attitude. [Also, since Microsoft has been working closely with Intel regarding Merced for several years now, and has yet to do anything `serious' - I believe they are taking the same wait-and-see approach. Likely while telling Intel otherwise.] SCO and IBM with their Monterey-64 project are considering Merced quite seriously. Actually, as far as I know, for Monterey-64 the availability of the Merceds seems to be the limiting factor now. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD??? Intel? - NOT
Jim Bryant wrote: I really don't know how people get started with this. HP has _never_ stated that the chip will handle it; all they have stated is that HPUX applications will continue to be supported. I suggest you people go read comp.arch for a while; there's a fair bit of information cropping up there. For example, there's a wonderful thread going on about HP's previous experience with architecture emulation, including some interesting comments by people at HP. Well, the way I understand things, HP-UX 11 comes in two flavors, 32 bits and 64 bits. I think that 32-bit code is handled in a legacy emulation under 64 bit 11, I'd have to double check that though with the book. PA-8000 (PA-RISC 2.0 architecture) has harware support for the 32-bit (PA-RISC 1.1 architecture) instructions. It's configured by one of the bits in the status register. Alas, HP does not have the PA-RISC 2.0 specs online but they have a whitepaper describing the additions in a nutshell. But I guess internally the system calls are implemented as 64-bit. Speaking about Merced, the same thing is done in SCO/IBM Monterey-64, all the kernel including the implementation of the 32-bit system calls (the UnixWare IA-32 compatibility subsystem) works in the 64-bit mode. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD??? Intel? - NOT
Zuidam, Hans wrote: Hi, The IA64 (merced) is a kind of VLIW (Very Large Instruction Word) processor. It is basically a complete new kind of systems architecture with a i686 (and of course a i586, ..., 4004) slapped on the side. The original processor design was done by HP. See: The IA-64 Architecture at Work, IEEE Computer Vol. 31, No. 7, July 1998 for a more informed description ;-) of the processor. Merced is not VLIW. VLIW means explicit parallelism of instructions, scheduled by the compiler. It also means that the code is tied very closely to the internal CPU architecture and would be incompatible between different CPUs of the same family. I can't remember now how the Merced architecture is named but it's a rudimentary data-flow machine with explicit synchronization points. Intel has an introduction to the Merced architecture on their Web-site. Also there was a talk at the SCO Forum about the Merced assembly language, I guess it should also be available online. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: font edit tools
Alexey M. Zelkin wrote: hi, Which tools can be used to edit syscons fonts ? Any of the tools you use to edit the DOS fonts. My favorite one it Evafont by Pete Kvitek. But there were a lot of tools floating around. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: font edit tools
Alexey M. Zelkin wrote: hi, Which tools can be used to edit syscons fonts ? Any of the tools you use to edit the DOS fonts. My favorite one it Evafont by Pete Kvitek. But there were a lot of tools floating around. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : Do we have a list of all services that use bpf? I'm willing to edit the man : pages, given a list. I guess I could just grep-o-matic here, huh? Yes. I'm also in a holding off pattern until we know the exact impact for all daemons that use this... I think I found a solution that may be better (although more complicated): Let the sysadmin to define a bpf filter for the packets that are considered OK (say, DHCP or RARP or RBOOT or whatever else this installation needs for normal functioning). Provide some typical examples. After this filter is defined and the system goes to a higher security level bpf first applies this filter to all the incoming packets, and only if they pass this filter they are checked for application-specified filters. If there is no such "master" filter defined then bpf can just deny new open()s as proposed earlier. This will allow the applications to use bpf but only for the purposes defined in the master filter. This also resolves the problem of services re-opening bpf after SIGHUP. And speaking on the issue of bpf enabled in GENERIC, I'm strongly pro it. Having bpf disabled is a big pain. May be it would be better to provide a separate prototype configuration file, say, SECURE with all the dangerous things disabled and explanations why they are disabled, so that peoples will think twice before re-enabling them. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message 37a3b701.851df...@softweyr.com Wes Peters writes: : Do we have a list of all services that use bpf? I'm willing to edit the man : pages, given a list. I guess I could just grep-o-matic here, huh? Yes. I'm also in a holding off pattern until we know the exact impact for all daemons that use this... I think I found a solution that may be better (although more complicated): Let the sysadmin to define a bpf filter for the packets that are considered OK (say, DHCP or RARP or RBOOT or whatever else this installation needs for normal functioning). Provide some typical examples. After this filter is defined and the system goes to a higher security level bpf first applies this filter to all the incoming packets, and only if they pass this filter they are checked for application-specified filters. If there is no such master filter defined then bpf can just deny new open()s as proposed earlier. This will allow the applications to use bpf but only for the purposes defined in the master filter. This also resolves the problem of services re-opening bpf after SIGHUP. And speaking on the issue of bpf enabled in GENERIC, I'm strongly pro it. Having bpf disabled is a big pain. May be it would be better to provide a separate prototype configuration file, say, SECURE with all the dangerous things disabled and explanations why they are disabled, so that peoples will think twice before re-enabling them. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. A problem is that rarpd does not understand the SIGHUP signal to reload the configuration (rbootd does). So if the RARP table needs to be modified then rarpd has to be restarted. I guess that the easiest way to fix it would be to add SIGHUP support to rarpd. And I think it's still worth mentioning in the documentation, to caution the sysadmins from killing and restarting the daemons dependent on bpf. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message 37a25361.34799...@bellatlantic.net Sergey Babkin writes: : Disabling bpf it will break rarpd (and also rbootd but it is less : important). I think such a thing should be mentioned in documentation. Not if they are started before the secure level is raised. A problem is that rarpd does not understand the SIGHUP signal to reload the configuration (rbootd does). So if the RARP table needs to be modified then rarpd has to be restarted. I guess that the easiest way to fix it would be to add SIGHUP support to rarpd. And I think it's still worth mentioning in the documentation, to caution the sysadmins from killing and restarting the daemons dependent on bpf. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: 37a30852.20e5a...@bellatlantic.netSergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? You can unload the user list from mySQL into a Berkeley db file and modify /etc/sendmail.cf to route the mail for the users listed in this file to a special delivery agent. And this special delivery agent would be a quite straightforward modification of /usr/libexec/mail.local. A variation of this would be to modify mail.local to add the data from mySQL database to getpwent, just like POP3 does, and instruct sendmail to process the mail for the extra users by mail.local. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of "raw devices". Disabling bpf it will break rarpd (and also rbootd but it is less important). I think such a thing should be mentioned in documentation. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
Warner Losh wrote: In message pine.bsf.4.10.9907301619280.6951-100...@janus.syracuse.net Brian F. Feldman writes: : And how about having : if (securelevel 3) : return (EPERM); : in bpf_open()? There are no security levels 3. I'd be happy with 0. This is consistant with the meaning of raw devices. Disabling bpf it will break rarpd (and also rbootd but it is less important). I think such a thing should be mentioned in documentation. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Daniel C. Sobral wrote: Mike Hoskins wrote: This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. I think that would rather be a function of the memory footprint of the workload. The message said memory was increased because Solaris was overloaded with _swapping_. The load itself isn't really of much importance in this case. I think there is some confusion. In case of swapping the workload (A.K.A. CPU run queue length) will be _low_. Intensive swapping/paging means overloaded I/O subsystem and underloaded CPU. If the CPU has high load then the paging does not make a big problem, it just happens in "background" and does not really affect the system performance limited by the CPU bottleneck. Well, it may also favor the CPU-intensive application and limit the I/O-intensive applications if the filesystems and swap areas are on the same disks. (Yes, I have seen both cases in the real life). Since Solaris does not overcommit, it needs (much) more memory than FreeBSD would. Thus, changing to FreeBSD and upgrading the memory at It does not. It needs more swap space configured but not the physical memory. And at the current disk prices a 9G SCSI disk configured for swap would cost under $300, so the difference is not _that_ big. Solaris is not a bad operating system. It's just misguided. :-) It's just terrible from the systems administration standpoint :-) -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Daniel C. Sobral wrote: Mike Hoskins wrote: This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. I think that would rather be a function of the memory footprint of the workload. The message said memory was increased because Solaris was overloaded with _swapping_. The load itself isn't really of much importance in this case. I think there is some confusion. In case of swapping the workload (A.K.A. CPU run queue length) will be _low_. Intensive swapping/paging means overloaded I/O subsystem and underloaded CPU. If the CPU has high load then the paging does not make a big problem, it just happens in background and does not really affect the system performance limited by the CPU bottleneck. Well, it may also favor the CPU-intensive application and limit the I/O-intensive applications if the filesystems and swap areas are on the same disks. (Yes, I have seen both cases in the real life). Since Solaris does not overcommit, it needs (much) more memory than FreeBSD would. Thus, changing to FreeBSD and upgrading the memory at It does not. It needs more swap space configured but not the physical memory. And at the current disk prices a 9G SCSI disk configured for swap would cost under $300, so the difference is not _that_ big. Solaris is not a bad operating system. It's just misguided. :-) It's just terrible from the systems administration standpoint :-) -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposed substitution for ACLs
Daniel C. Sobral wrote:
Sergey Babkin wrote:
I want to propose a simple substitution for ACLs. No, here
is no patch yet but I'm ready and willing to do it. The reason
why I want to discuss it first is that this is a Political Thing.
And if the Core Team decides that it's a Bad Thing, I suppose
it will never get commited to the system. Because of this I
would like to see some encouraging signs from the Core Team
before implementing it.
Do whatever you want: as a fs layer.
Speaking about the fs layers, can you please advise me on the current
state of nullfs ? Is it working now ? I have checked GNATS about this
and did not quite understood whether the results of a lengthly
discussion in there on this subject were ever committed.
On the other hand, I'm not sure whether implementing it as an FS
layer is a good idea. It is certainly possible to do by snooping
at the getattr/setattr calls but IMHO it will mean completely bypassing
the VOP_ACCESS of the underlying filesystem what may be not good.
On the other hand the changes to ufs_assess() seem to be quite small
and cover all the UFS type filesystems, such as FFS and EXT2FS.
Of course yet another option is to create one more fs type with all
the operations in the filesystem switch the same as for FFS except
for ufs_access().
What would be your recommendation ? Thanks!
Here is the proposed patch (made against 3.2). If it will be
considered OK I'll write some man page and LINT kernel entry too.
I'm not sure whether the sysctl sub-node vfs.ufs is really neccessary
but it seems to be logical.
-- cut here -
*** /sys/ufs/ufs/ufs_vnops.c1999/07/15 14:50:53 1.1
--- /sys/ufs/ufs/ufs_vnops.c1999/07/22 18:16:28
***
*** 57,62
--- 57,63
#include sys/dirent.h
#include sys/lockf.h
#include sys/poll.h
+ #include sys/sysctl.h
#include vm/vm_zone.h
#include vm/vm.h
***
*** 104,109
--- 105,128
static int ufsspec_read __P((struct vop_read_args *));
static int ufsspec_write __P((struct vop_write_args *));
+ #ifdef ENABLE_UFS_COMMONID
+ /*
+ * Sysctl variables to control the unified user and
+ * group ID space.
+ * commonid is the lowest ID from which the common UID/GID space starts
+ * MINCOMMONID is the minimal value, if commonid is lower then the
+ * common ID space is disabled
+ */
+
+ #define MINCOMMONID 100
+
+ SYSCTL_NODE(_vfs, OID_AUTO, ufs, CTLFLAG_RW, 0, "Local Unix-type filesystems");
+ static int commonid=0;
+ SYSCTL_INT(_vfs_ufs, OID_AUTO, commonid, CTLFLAG_RW, commonid, 0,
+ "Lowest ID for the common GID/UID space");
+
+ #endif
+
union _qcvt {
int64_t qcvt;
int32_t val[2];
***
*** 339,344
--- 360,382
mask |= S_IWUSR;
return ((ip-i_mode mask) == mask ? 0 : EACCES);
}
+
+ #ifdef ENABLE_UFS_COMMONID
+ /* if the common UID/GID is enabled check the groups against the file UID */
+ if (commonid = MINCOMMONID ip-i_uid = commonid) {
+ for (i = 0, gp = cred-cr_groups; i cred-cr_ngroups;
+ i++, gp++)
+ if (ip-i_uid == *gp) {
+ if (mode VEXEC)
+ mask |= S_IXUSR;
+ if (mode VREAD)
+ mask |= S_IRUSR;
+ if (mode VWRITE)
+ mask |= S_IWUSR;
+ return ((ip-i_mode mask) == mask ? 0 : EACCES);
+ }
+ }
+ #endif
/* Otherwise, check the groups. */
for (i = 0, gp = cred-cr_groups; i cred-cr_ngroups; i++, gp++)
--- cut here
-SB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed substitution for ACLs
Daniel C. Sobral wrote:
Sergey Babkin wrote:
I want to propose a simple substitution for ACLs. No, here
is no patch yet but I'm ready and willing to do it. The reason
why I want to discuss it first is that this is a Political Thing.
And if the Core Team decides that it's a Bad Thing, I suppose
it will never get commited to the system. Because of this I
would like to see some encouraging signs from the Core Team
before implementing it.
Do whatever you want: as a fs layer.
Speaking about the fs layers, can you please advise me on the current
state of nullfs ? Is it working now ? I have checked GNATS about this
and did not quite understood whether the results of a lengthly
discussion in there on this subject were ever committed.
On the other hand, I'm not sure whether implementing it as an FS
layer is a good idea. It is certainly possible to do by snooping
at the getattr/setattr calls but IMHO it will mean completely bypassing
the VOP_ACCESS of the underlying filesystem what may be not good.
On the other hand the changes to ufs_assess() seem to be quite small
and cover all the UFS type filesystems, such as FFS and EXT2FS.
Of course yet another option is to create one more fs type with all
the operations in the filesystem switch the same as for FFS except
for ufs_access().
What would be your recommendation ? Thanks!
Here is the proposed patch (made against 3.2). If it will be
considered OK I'll write some man page and LINT kernel entry too.
I'm not sure whether the sysctl sub-node vfs.ufs is really neccessary
but it seems to be logical.
-- cut here -
*** /sys/ufs/ufs/ufs_vnops.c1999/07/15 14:50:53 1.1
--- /sys/ufs/ufs/ufs_vnops.c1999/07/22 18:16:28
***
*** 57,62
--- 57,63
#include sys/dirent.h
#include sys/lockf.h
#include sys/poll.h
+ #include sys/sysctl.h
#include vm/vm_zone.h
#include vm/vm.h
***
*** 104,109
--- 105,128
static int ufsspec_read __P((struct vop_read_args *));
static int ufsspec_write __P((struct vop_write_args *));
+ #ifdef ENABLE_UFS_COMMONID
+ /*
+ * Sysctl variables to control the unified user and
+ * group ID space.
+ * commonid is the lowest ID from which the common UID/GID space starts
+ * MINCOMMONID is the minimal value, if commonid is lower then the
+ * common ID space is disabled
+ */
+
+ #define MINCOMMONID 100
+
+ SYSCTL_NODE(_vfs, OID_AUTO, ufs, CTLFLAG_RW, 0, Local Unix-type
filesystems);
+ static int commonid=0;
+ SYSCTL_INT(_vfs_ufs, OID_AUTO, commonid, CTLFLAG_RW, commonid, 0,
+ Lowest ID for the common GID/UID space);
+
+ #endif
+
union _qcvt {
int64_t qcvt;
int32_t val[2];
***
*** 339,344
--- 360,382
mask |= S_IWUSR;
return ((ip-i_mode mask) == mask ? 0 : EACCES);
}
+
+ #ifdef ENABLE_UFS_COMMONID
+ /* if the common UID/GID is enabled check the groups against the file
UID */
+ if (commonid = MINCOMMONID ip-i_uid = commonid) {
+ for (i = 0, gp = cred-cr_groups; i cred-cr_ngroups;
+ i++, gp++)
+ if (ip-i_uid == *gp) {
+ if (mode VEXEC)
+ mask |= S_IXUSR;
+ if (mode VREAD)
+ mask |= S_IRUSR;
+ if (mode VWRITE)
+ mask |= S_IWUSR;
+ return ((ip-i_mode mask) == mask ? 0 :
EACCES);
+ }
+ }
+ #endif
/* Otherwise, check the groups. */
for (i = 0, gp = cred-cr_groups; i cred-cr_ngroups; i++, gp++)
--- cut here
-SB
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
Garance A Drosihn wrote: At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: In which case the program that consumed all memory will be killed. The program killed is +NOT+ the one demanding memory, it's the one with most of it. But that isn't always the best process to have killed off... One of my main freebsd machines is mainly here to run one process, which is a pretty good-sized process (40meg). If I did get into a memory-shortage problem, I do *not* want that process killed, I'd want some other processes killed. It would be nice to have a way to indicate that, a la SIGDANGER. Another option may be to add something like "importance classes". Suppose we assign an one-byte "importance level" to each process. When we get out of swap we start killing processes with the lowest importance level. This seems to be both easy to implement and a rather robust solution. It can be extended to more flexible policies: say, we divide this 8-bit number into two 4-bit fields. The high field will be "major importance level" the low field will be "importance sublevel". We permit the user processes to change their sublevel to any value as long their major level stays the same or becomes lower. This will allow the users to make differences between their programs but only in certain limits. The initial importance level may be set in /etc/login.conf. One more extension would be to use one bit as the ihneritance flag: if it is set, the child inherits the importance value from the parent. But if it's reset the child inherits its major level from the parent but the sublevel gets reset to 0. It may be useful for transparent calls of system(). Yet another extension would be to use two separate inheritance bits: one as described above, the secone one if reset means that the importance value of the child must be reset to the lowest one. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
Garance A Drosihn wrote: At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: In which case the program that consumed all memory will be killed. The program killed is +NOT+ the one demanding memory, it's the one with most of it. But that isn't always the best process to have killed off... One of my main freebsd machines is mainly here to run one process, which is a pretty good-sized process (40meg). If I did get into a memory-shortage problem, I do *not* want that process killed, I'd want some other processes killed. It would be nice to have a way to indicate that, a la SIGDANGER. Another option may be to add something like importance classes. Suppose we assign an one-byte importance level to each process. When we get out of swap we start killing processes with the lowest importance level. This seems to be both easy to implement and a rather robust solution. It can be extended to more flexible policies: say, we divide this 8-bit number into two 4-bit fields. The high field will be major importance level the low field will be importance sublevel. We permit the user processes to change their sublevel to any value as long their major level stays the same or becomes lower. This will allow the users to make differences between their programs but only in certain limits. The initial importance level may be set in /etc/login.conf. One more extension would be to use one bit as the ihneritance flag: if it is set, the child inherits the importance value from the parent. But if it's reset the child inherits its major level from the parent but the sublevel gets reset to 0. It may be useful for transparent calls of system(). Yet another extension would be to use two separate inheritance bits: one as described above, the secone one if reset means that the importance value of the child must be reset to the lowest one. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Proposed substitution for ACLs
Hi! I want to propose a simple substitution for ACLs. No, here is no patch yet but I'm ready and willing to do it. The reason why I want to discuss it first is that this is a Political Thing. And if the Core Team decides that it's a Bad Thing, I suppose it will never get commited to the system. Because of this I would like to see some encouraging signs from the Core Team before implementing it. Now to the issue itself. ACLs are a popular thing nowadays and as far as I know FreeBSD does not have it yet. But although everyone boasts with their ACL support I think nobody is really using it (and if somebody is using it then I think it's often not the best decision). ACLs have obvious drawbacks: - they are not supported by the standard file formats like tar or cpio - they need lots of ugly flags for the commands like chown or ls, and some new ugly commands - they are just by themselves difficult to show clearly in ls - they are a mess and promote ad-hoc assignment of permissions For example, Netware suports ACLs and I have seen by myself what mess the sysadmins who have head problems are able to create with them. But in fact the classic Unix permissions seem to have only one real problem: sometimes it's neccessary to give read permissions to one group of users and read-write permissions to another group of users. But Unix permissions support permissions for only one group and that makes the problem. A simple solution would be to add the second group but this would also break the compatibility. I propose to re-use the "uid" field to held the permissions for the second group. Suppose we do the following: 1. Add a sysctl flag enabling or disabling (by default) the extended permissions. That should completely cover the compatibility issues. 2. Sysadmin uses unique IDs for the users and groups in the common ID space. Say, if there is a user with ID=2000 then there must be no group with ID=2000 (except a special case described later). Traditionally there is such overlapping in the low IDs, so let's enable the new behavior only for IDs 1000 (or some other number, possibly another sysctl parameter). 3. Implement the following semantics (a simple and straightforward addition to ufs_access() ): if the new behavior is enabled and the file owner's ID is over 1000 (or a sysctl parameter) then in addition to comparing the process'es UID with the file owner ID we compare all process'es group IDs with the file owner ID and if any of them matches we use the "owner" permissions for this process. So, in effect we consider the file owner ID as both user and group number, and the described problem with two groups with different permissions is solved. 4. The described semantics is used only for file access but not modification of the access rights, the "owner group" can't modify the permissions of the file. And here we come to the special case mentioned in p.2: if there is an user with UID equal to the GID of the "owner group" such user can modify the permissions. This user may be a pseudo-user created together with the group. If we want to give the "owner group" the right to change all permissions of its files we can just do something like (suppose whe have user `mygrp' and group `mygrp' with the same ID): # cp /bin/chmod /usr/local/bin/mygrpchmod # chown mygrp /usr/local/bin/mygrpchmod # chmod 500 /usr/local/bin/mygrpchmod # chmod u+s /usr/local/bin/mygrpchmod The same thing may be ised for chown. In result all the group members will be able to execute mygrpchmod, and when it will be executed it will assume the EUID of the user mygrp and will be able the file permissions. Or we can do `chmod 050' and give the permission to modify all the permissions of this "owner group" to another group of users. Having a pseudo-user with the same ID as a group also gives for free `ls' showing the right symbolic owner name. 5. If this behavior is wanted on NFS, that can be done too. Probably, with a separate sysctl flag. These additions give essentially the same flexibility as ACLs give but without any change in the i-node format, ls and tar/cpio formats, don't really need any special programs nor flags to manipulate them. Though a few user-level additions may be added for convenience, such as automatic addition of a pseudo-user for each defined group, check for user/group ID conflicts, multi-level groups, additional programs to give better granularity of control over file permissions. That's all. I think the idea is rather simple and clean. Any comments are welcome. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Proposed substitution for ACLs
Hi! I want to propose a simple substitution for ACLs. No, here is no patch yet but I'm ready and willing to do it. The reason why I want to discuss it first is that this is a Political Thing. And if the Core Team decides that it's a Bad Thing, I suppose it will never get commited to the system. Because of this I would like to see some encouraging signs from the Core Team before implementing it. Now to the issue itself. ACLs are a popular thing nowadays and as far as I know FreeBSD does not have it yet. But although everyone boasts with their ACL support I think nobody is really using it (and if somebody is using it then I think it's often not the best decision). ACLs have obvious drawbacks: - they are not supported by the standard file formats like tar or cpio - they need lots of ugly flags for the commands like chown or ls, and some new ugly commands - they are just by themselves difficult to show clearly in ls - they are a mess and promote ad-hoc assignment of permissions For example, Netware suports ACLs and I have seen by myself what mess the sysadmins who have head problems are able to create with them. But in fact the classic Unix permissions seem to have only one real problem: sometimes it's neccessary to give read permissions to one group of users and read-write permissions to another group of users. But Unix permissions support permissions for only one group and that makes the problem. A simple solution would be to add the second group but this would also break the compatibility. I propose to re-use the uid field to held the permissions for the second group. Suppose we do the following: 1. Add a sysctl flag enabling or disabling (by default) the extended permissions. That should completely cover the compatibility issues. 2. Sysadmin uses unique IDs for the users and groups in the common ID space. Say, if there is a user with ID=2000 then there must be no group with ID=2000 (except a special case described later). Traditionally there is such overlapping in the low IDs, so let's enable the new behavior only for IDs 1000 (or some other number, possibly another sysctl parameter). 3. Implement the following semantics (a simple and straightforward addition to ufs_access() ): if the new behavior is enabled and the file owner's ID is over 1000 (or a sysctl parameter) then in addition to comparing the process'es UID with the file owner ID we compare all process'es group IDs with the file owner ID and if any of them matches we use the owner permissions for this process. So, in effect we consider the file owner ID as both user and group number, and the described problem with two groups with different permissions is solved. 4. The described semantics is used only for file access but not modification of the access rights, the owner group can't modify the permissions of the file. And here we come to the special case mentioned in p.2: if there is an user with UID equal to the GID of the owner group such user can modify the permissions. This user may be a pseudo-user created together with the group. If we want to give the owner group the right to change all permissions of its files we can just do something like (suppose whe have user `mygrp' and group `mygrp' with the same ID): # cp /bin/chmod /usr/local/bin/mygrpchmod # chown mygrp /usr/local/bin/mygrpchmod # chmod 500 /usr/local/bin/mygrpchmod # chmod u+s /usr/local/bin/mygrpchmod The same thing may be ised for chown. In result all the group members will be able to execute mygrpchmod, and when it will be executed it will assume the EUID of the user mygrp and will be able the file permissions. Or we can do `chmod 050' and give the permission to modify all the permissions of this owner group to another group of users. Having a pseudo-user with the same ID as a group also gives for free `ls' showing the right symbolic owner name. 5. If this behavior is wanted on NFS, that can be done too. Probably, with a separate sysctl flag. These additions give essentially the same flexibility as ACLs give but without any change in the i-node format, ls and tar/cpio formats, don't really need any special programs nor flags to manipulate them. Though a few user-level additions may be added for convenience, such as automatic addition of a pseudo-user for each defined group, check for user/group ID conflicts, multi-level groups, additional programs to give better granularity of control over file permissions. That's all. I think the idea is rather simple and clean. Any comments are welcome. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
boot troubles in 3.1
Hi! I have tried to install 3.1 on two machines but on both of them I was not able to boot it after installation. The 3.0-snapshot from May-98 worked fine on both of them. But 3.1 did not boot. First, the MBR boot manager was not able to boot any partition, nor FreeBSD nor UnixWare. After I replaced it with boot manager from 3.0 it worked but then some later stage of the boot was not able to find the kernel. Both machines have Phoenix BIOS (one is Intel, another Unisys). One has IDE disk, another has SCSI. I'm about to look at the problem but want to make sure first that it's not a known bug that was fixed long ago (sorry, I have not tracked -hackers for about half a year). Any information will be appreciated. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD FibreChannel support
Matthew Jacob wrote: What gives? Why wasn't this committed to the NetBSD and FreeBSD trees, too? I mean, it's not like the version in the NetBSD tree works anymore since you removed the firmware (on-board firmware on most of the adapters I have is way too old, for example). Any reason NetBSD and FreeBSD don't just lift the firmware images you committed to OpenBSD? Because what I did was wrong. It should also be removed from OpenBSD. I've had extensive discussions with Theo about this, and the f/w will probably be removed from OpenBSD as soon as the tree unlocks post 2.6. Unless Qlogic agrees to a BSD style licence. So far, they've not been helpful at all. The QLogic firmware can be downloaded from the Qlogic WWW site (for 2100 there is a link on the page http://www.qlc.com/bbs-html/qla2100.html , I guess the same it true for the other boards) and flashed onto the board. I'm not sure about the Alpha systems but on PC their flash utility works fine. I used it recently to get it working with a commercial Unix. Or is it some different kind of firmware ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
