sysctl interface for apm?
I was paging through the distributed.net client changelog and they had a note there basically asking for a sysctl interface to apm -- in short, they wanted the ability for non-root users to detect power state (AC/batt) and battery level. At first, I wondered why they regarded this differently from opening /dev/apm and doing the requisite ioctl()s. Then I looked at /dev/apm's permissions and saw the problem. So what does everyone think? Is it suitable to add a read only sysctl 'machdep.apm_powerstate' that reports either AC, nn%, or N/A ? Or should the format be numeric (999 = AC, <=100 = battery %, -1 = N/A)? Or should we not bother? :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Core-team statement: fruitless discussions in the mailing lists
Several members of the FreeBSD community approached us with different request regarding Brett Glass' behaviour in our mailing lists. For various reasons we do not want to `blacklist' anyone from using the FreeBSD mailing lists, but we remind everybody here to not contribute to fruitless and often off-topic discussions. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) PGP signature
Re: config and config -r
In message <[EMAIL PROTECTED]> Maxime Henrion writes: : But after rebooting on this new kernel, I had a page fault before : any kernel message :/ Is there anything to check in order to know if I : can use a config instead of a config -r ? If using a config without the : -r option is dangerous, I think it shouldn't be the default. Is it the : case ? Make depend is required if you ever want to build kernels more than once. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: options INET6 vs opt_inet.h
Darren Reed wrote: > > So, it would appear that in /sys/conf/options, we have the following: > > INETopt_inet.h > INET6 opt_inet6.h > > Which might seem all nice and dandy - except that config will not generate > "opt_inet6.h" with "#undef INET6" if "option INET6" is not present and so > you cannot inlcude "opt_inet6.h" to determine if INET6 is defined. There > are two possible fixes here - which are not necessarily mutually exclusive > of each other: > > 1. make config generate opt_inet6.h anyway Umm.. but it does already! peter@beast[8:42pm]~src/sys/i386/conf-103> grep INET6 TEST #optionsINET6 #IPv6 communications protocols peter@beast[8:42pm]~src/sys/i386/conf-104> rm ../../compile/TEST/opt_inet6.h peter@beast[8:42pm]~src/sys/i386/conf-105> config TEST Don't forget to do a ``make depend'' Kernel build directory is ../../compile/TEST peter@beast[8:42pm]~src/sys/i386/conf-106> cat ../../compile/TEST/opt_inet6.h peter@beast[8:45pm]~src/sys/i386/conf-107> vi TEST peter@beast[8:45pm]~src/sys/i386/conf-109> grep INET6 TEST options INET6 #IPv6 communications protocols peter@beast[8:45pm]~src/sys/i386/conf-110> config TEST Don't forget to do a ``make depend'' Kernel build directory is ../../compile/TEST peter@beast[8:45pm]~src/sys/i386/conf-111> cat ../../compile/TEST/opt_inet6.h #define INET6 1 peter@beast[8:45pm]~src/sys/i386/conf-112> > 2. put INET6 in opt_inet.h > > I believe that (2) is quite reasonable but (1) should happen anyway. > > Comments ? I'm not sure what you think is happening, but it most certainly does generate opt_inet6.h as expected. (Well, it doesn't put #indef INET6 in it, but there is no point wasting space doing that..) > Darren Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Interrupt Handler?
On Thursday, 13 July 2000 at 22:51:56 -0400, Brandon Fosdick wrote: > Where/How does one implement a hardware interrupt handler? I haven't > done this sort of thing since the days of DOS. I imagine its a lot > different in *nix. :) The low-level interrupt handlers are in /usr/src/sys/i386/isa/exception.s. Your device driver attach routine will register its interrupt routine with BUS_SETUP_INTR, which will cause the appropriate interrupt handler to transfer control to your interrupt handler when an interrupt occurs. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
options INET6 vs opt_inet.h
So, it would appear that in /sys/conf/options, we have the following: INETopt_inet.h INET6 opt_inet6.h Which might seem all nice and dandy - except that config will not generate "opt_inet6.h" with "#undef INET6" if "option INET6" is not present and so you cannot inlcude "opt_inet6.h" to determine if INET6 is defined. There are two possible fixes here - which are not necessarily mutually exclusive of each other: 1. make config generate opt_inet6.h anyway 2. put INET6 in opt_inet.h I believe that (2) is quite reasonable but (1) should happen anyway. Comments ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PR 18593: *is* VOP_LOOKUP a 'VFS entry point' ?
PR 18593 says that VOP_LOOKUP is not a 'VFS entry point', so like a fool I believed it and committed the manpage diff within it. :-( All the other VOP* manual pages just say "entry point", but VOP_LOOKUP(9) said "VFS entry point", the patch changed that to be consistent with the rest. Can someone confirm one way or the other, and pass me the pointy hat for the first time if needed? Hmm, pointy hat within a week, not good. :-( thanks. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / PGP signature
Re: Boot loader problem workaround
From: "Doug White" <[EMAIL PROTECTED]> To: "Gemini Domino" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, July 15, 2000 17:59 Subject: Re: Boot loader problem workaround > > It would be nice if a command like > > fdisk -a -1 ad0 > > would just set it instead of asking. > > Doug White| FreeBSD: The Power to Serve > [EMAIL PROTECTED] | www.FreeBSD.org > > Thats sorta what I had in mind, though I think there's gonna be some EXPECTing involved... * "To live alone one must be a beast or a god, says Aristotle. Leaving out the third case: one must be both -- a philosopher" "The better the state is established, the fainter is humanity. To make the individual uncomfortable, that is my task." "A great value of antiquity lies in the fact that its writings are the only ones that modern men still read with exactness." "The bite of conscience, like the bite of a dog into a stone, is a stupidity." Friedrich Wilhelm Nietzsche To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot loader problem workaround
On Sat, 15 Jul 2000, Gemini Domino wrote: > There's been a problem reported by several people on multi-HD multiboot > systems about the bootloader clearing active flags and making it impossible > to reboot without using a boot disk to use FDISK to reset the active flag. > This was solved by turning on the "noupdate" option with boot0cfg, but I had > another idea I thought you hackers could help me with. Since I rather liked > the default partition being set to the last one used (this is what caused > the problem) it occured to me to use FreeBSDs fdisk to reset the active flag > on ad0 (maybe in rc). What I cant find is whether or not there is a > non-interactive way of doing so. I looked into using a configfile, but that > nukes the partition tables. Anyone wanna play with this or have any input? It would be nice if a command like fdisk -a -1 ad0 would just set it instead of asking. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: config and config -r
Please don't crosspost. -questions would have been more appropriate for this. Maxime Henrion wrote: > Is there anything to check in order to know if I > can use a config instead of a config -r ? This may sound flippant, but it isn't meant to be. If config without the -r works (which it does most of the time) it works, and it's safe to use. If it doesn't work, you should go back and use config -r. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: config and config -r
Maxime Henrion wrote: > As I didn't want to recompile the whole stuff, I used a config and > not a config -r to build a new kernel, after having changed its > configuration. I removed several devices and I thought that won't cause > any problem, as the objects files for these devices won't be linked into > the kernel. Did you do a "make depend"? I personally have never had a problem with just "config" rather than "config -r". > But after rebooting on this new kernel, I had a page fault before > any kernel message :/ Is there anything to check in order to know if I > can use a config instead of a config -r ? If using a config without the > -r option is dangerous, I think it shouldn't be the default. Is it the > case ? "-r" used to be the default, you had to use "-n" to get the current behaviour of _not_ removing the directory. This was changed 2 years ago... | revision 1.20 | date: 1998/02/18 04:15:04; author: eivind; state: Exp; lines: +9 -13 | Make '-n' the default, and introduce a new flag '-r' to get old | behaviour. Also indicate which option(s) are unknown if there are any | old-style options. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D FreeBSD Documentation Project / PGP signature
config and config -r
Hello, I think the config program used to compile a kernel lacks some documentation because there are several points that remain unclear to me, even after reading the man page. I had several bad surprises with it ! :-) As I didn't want to recompile the whole stuff, I used a config and not a config -r to build a new kernel, after having changed its configuration. I removed several devices and I thought that won't cause any problem, as the objects files for these devices won't be linked into the kernel. But after rebooting on this new kernel, I had a page fault before any kernel message :/ Is there anything to check in order to know if I can use a config instead of a config -r ? If using a config without the -r option is dangerous, I think it shouldn't be the default. Is it the case ? Regards, -Maxime Henrion To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
different clocks in FreeBSD
Hey, I want to get the accurate user-time and system-time used by a process whenever I want. My code will run inside the kernel. I try to use the getrusage from within the kernel, but the function didn't give right data. Then I try to read the p_uticks in the proc structure. But it seems that value is not accurate enough because it will be zero when the actual user time is small(e.g., 20microsecond). I guess it is because the frequency of the statclock is not high enough( stathz=128 from the kern_clockrate). So, I have the following questions: 1. Can I use getrusage from within the kernel to get the utime and stime? 2. Can I use the p_uticks and p_sticks as the utime and stime of the system? What's the meaning of p_uu and p_su? What's the meaning of the 'tick' in the comments of these variable? Stat tick or sched tick or anything else? 3. If I have to change the stathz(currently 128, as reported by kern_clockrate), where should I change in the source code? 4. Is it possible to get the accurate utime and stime at any time, but do not have to change the stathz(I worry about it will not efficient). I plan to insert some code when interrupt and context switch occured. Is it difficult? thank you! -Song To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: port of MPPE (microsoft VPN encryption) to FreeBSD
Hi Ben, If you can go to 4.0s, there is /usr/ports/net/mpd-netgraph which works great already, and doesn't requre poptop at all. It does require a buildworld with the most recent sources... -steve > "Ben" == Ben Jackson <[EMAIL PROTECTED]> writes: Ben> I needed MPPE to tunnel into work and found: Ben> http://www.moretonbay.com/vpn/releases/ppp-2.3.10-openssl-norc4-mppe.patch.gz Ben> which applies to ppp-2.3.10 and adds MS CHAP v1 and v2 and Ben> MPPE to pppd and the related kernel code. Imagine my Ben> surprise when I found that only the CHAP parts were portable Ben> and the MPPE was only available for Linux! So, in a process Ben> not unlike hammering a square peg into a round hole, I got Ben> the kernel components working under FreeBSD 3.4. Ben> Has anyone else already done this? Is anyone mbuf-savvy Ben> interetested in suggesting more elegant ways of supporting Ben> this code for BSD? My main purpose in sending this is to Ben> make sure any interested parties pester me so I get around to Ben> sharing the results... Ben> --Ben Ben> To Unsubscribe: send mail to [EMAIL PROTECTED] with Ben> "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Boot loader problem workaround
There's been a problem reported by several people on multi-HD multiboot systems about the bootloader clearing active flags and making it impossible to reboot without using a boot disk to use FDISK to reset the active flag. This was solved by turning on the "noupdate" option with boot0cfg, but I had another idea I thought you hackers could help me with. Since I rather liked the default partition being set to the last one used (this is what caused the problem) it occured to me to use FreeBSDs fdisk to reset the active flag on ad0 (maybe in rc). What I cant find is whether or not there is a non-interactive way of doing so. I looked into using a configfile, but that nukes the partition tables. Anyone wanna play with this or have any input? Thanks GGD * "To live alone one must be a beast or a god, says Aristotle. Leaving out the third case: one must be both -- a philosopher" "The better the state is established, the fainter is humanity. To make the individual uncomfortable, that is my task." "A great value of antiquity lies in the fact that its writings are the only ones that modern men still read with exactness." "The bite of conscience, like the bite of a dog into a stone, is a stupidity." Friedrich Wilhelm Nietzsche To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
On Sat, Jul 15, 2000, Boris Popov wrote: > On Sat, 15 Jul 2000, Poul-Henning Kamp wrote: > > > In message <[EMAIL PROTECTED]>, Coleman Kane writes: > > > > >Who is currently working on the DEVFS? I emailed the last person > > >to commit to the HOWTO and got no response. I'd like to look into > > >finisheing this, and may start hacking if no one tells me otherwise... > > > > bp@ has a non-working prototype, (as has julian@). > > Poul, I've made a mistake sending you an out of sync and not > finished code. > > > None of them fixes the root-mount kludges. > > True, it requires some changes to VFS synch code. > > > None of them implement cloning devices. > > Again, wrong. If you disagree on what I've proposed it doesn't > mean that it didn't work. It is _necessary_ to fix make_dev() > usage/implementation to make cloning code clean. Ok, how about you, phk and julian throw up a list of what devfs should do? I am forming some ideas on how to solve the namespace and device cloning issues, we might make some forward work on this finally? :-) Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the <[EMAIL PROTECTED]>rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fsck_ext2fs
On Fri, Jul 14, 2000, Roman Shterenzon wrote: > Hello, > I was looking for fsck_ext2fs and found that openbsd has it. > So, I tried to compile it on freebsd, and it compiled very easy. > I needed just some minor modifications to make it work. > I send the tarball which has the modified version together with the > patchfile. > It seems to work for me. > Perhaps someone will make a use of it. Sweet! I shall look at this once my fsck wrappers stuff finally gets committed, so you can stick an ext2 fs in /etc/fstab and have it fscked for you at boot. Chances are right now people would prefer this as a port. Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the <[EMAIL PROTECTED]>rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
On Sat, 15 Jul 2000, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Coleman Kane writes: > > >Who is currently working on the DEVFS? I emailed the last person > >to commit to the HOWTO and got no response. I'd like to look into > >finisheing this, and may start hacking if no one tells me otherwise... > > bp@ has a non-working prototype, (as has julian@). Poul, I've made a mistake sending you an out of sync and not finished code. > None of them fixes the root-mount kludges. True, it requires some changes to VFS synch code. > None of them implement cloning devices. Again, wrong. If you disagree on what I've proposed it doesn't mean that it didn't work. It is _necessary_ to fix make_dev() usage/implementation to make cloning code clean. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
>> None of them fixes the root-mount kludges. > >actually the code you and SOS delted DID solve that No it didn't. rootvn was still magically wired from rootdev, with DEVFS mounted first it could be looked up with namei in a proper fashion. >> None of them implement cloning devices. >no, though have you tried looking at ptys under devfs.. >as you use them, more are created.. (a bit of a hack but kinda cute). Cute, but not cute enough. We have several devices which do this by now, but we need full cloning ability. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DEVFS
Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Coleman Kane writes: > > >Who is currently working on the DEVFS? I emailed the last person > >to commit to the HOWTO and got no response. I'd like to look into > >finisheing this, and may start hacking if no one tells me otherwise... Well, it was almost fully working before soem core members decided to delete part of the support code for no apparent reason. However there are some new design criteria that need to be considered that the old devfs didn't consider. (that is why one makes a prototype, so that one learns what is important). For example, it turns out that one of the important items a devfs needs to take into account is the ability for an operator to populate chroot/jail regions with a subset of devices. Puting a mountpoint for a devfs on each jail (there could be thousands) is not a winning solution. This suggests that the base filesystem needs to be involved in some way. Also the probing of new devices and disk partitions as they are loaded and created can be problematic. (that is what the deleted code did). I am now of the opinion that there needs to be a kernel devd which is responsible for probing out new partition hierarchies (with it's own context), and other actions within the devfs. it is even possible, given Poul-henning's device nodes within the kernel that much of the functionality that is looked for with devfs can be achieved via other means. Certainly the whole concept is up for discussion. > > bp@ has a non-working prototype, (as has julian@). > > None of them fixes the root-mount kludges. actually the code you and SOS delted DID solve that > > None of them implement cloning devices. no, though have you tried looking at ptys under devfs.. as you use them, more are created.. (a bit of a hack but kinda cute). > > If you (or a group of people) seriously want to work on DEVFS, send > me an email and I will coordinate and try to make sure we get this > done *right* so that we cover all the issues we need to cover with > devfs (root-mount, jail, cloning etc etc) Of better still email me too. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
