Re: Request for Review: Generate /etc/services from the IANA registry

[Steffen Nurpmeso]

Eric van Gyzen wrote in :
 |On 9/11/18 10:04 AM, Steffen Nurpmeso wrote:
 |> Alan Somers wrote in  w...@mail.gmail.com>:
 |>|Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
 |>|even after Eric's patch.  His Python script will only need to be run \
 |>|whenever IANA
 |>|updates its database, and the results will be checked into source contro\
 |>|l.  So for a normal user, there is no change to "make buildworld && make
 |>|installworld".
 |> 
 |> I cannot, unfortunately.  I use binary updates and even
 |> preinstalled VM images (thanks for that, by the way).
 |
 |So there will be no impact on you at all, except that /etc/services will 
 |have a lot more services.  As Alan said, Python and XML will only be 
 |added to the developer workflow.

Oh please, of course.  For me personally the FreeBSD version is
good enough anyway, it is just that i discovered this script for
a pretty common Linux distribution, and adopted it for a lesser
common one when there was a need to update the DBs.  To be honest
i have discovered it in the packaging system in some repository,
and that is a pity.  FreeBSD as i got to know it, and i would have
snooped around in /usr/share/misc of a default install in that
case first, and if i would have been lucky i would have discovered
good stuff to help me out.  That is all.

 |>|As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
 |>|can't easily handle things like IANA's representation of aliases, and \
 |>|it can't
 |>|easily format the list in the same order as our current list.  Python \
 |>|is truly a better choice.
 |> 
 |> I absolutely fail to see what you mean.  The script (which is in
 |> actual use, mind you) generates the desired output except that
 |> comments get lost, but this could be added upon interest, of
 |> course.  It (or a derivative) would have been a good candidate for
 |> /usr/share/misc/ in elder times i guess, too.
 |
 |That awk script depends on the formatting of the XML file.  It will 
 |break if the IANA decides to format it differently.  Granted, this is 
 |unlikely, but it's possible.

If you argue like this, anything is possible, is it.  If IANA
changes the XML tags, the Python script needs to be adjusted, too.
And if you ask me, i would vote for, and change to JSON.  No
offense, i said the same on a Unicode list, for example.

 |Also, that script would become much more complex if it supported local 
 |additions and overrides, which are unfortunately necessary in our case.

Come one.  I mean, come on.  What are you talking about?  You have
written these things, and they will likely enter FreeBSD.  This
does not make it just just any better in my eyes.  (Though the
counting program could be adjusted and be used as a test if the
sorted output would be compared against a sed(1) run on
/etc/services.)  If it would be me, a very small awk script would
enter /usr/share/misc, and some makefile would be adjusted and
call it, or a duplicate.  Base system self-contained, and some
nice hint to be found for someone who looks around.

I mean, i really looked out of interest at some review page in the
webbrowser (glad that you posted this for people who do not like
browsers that much, or get email notifications or whatever), which
was so large or whatever, anyway it blocked the tab.  Isn't that
absurd for a simple update framework for IANA databases in /etc?
(And what about protocols, by the way.)
Just my one cent, of course.  I am not even a developer.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Eric van Gyzen]

On 9/11/18 10:04 AM, Steffen Nurpmeso wrote:

Alan Somers wrote in :
  |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
  |even after Eric's patch.  His Python script will only need to be run \
  |whenever IANA
  |updates its database, and the results will be checked into source contro\
  |l.  So for a normal user, there is no change to "make buildworld && make
  |installworld".

I cannot, unfortunately.  I use binary updates and even
preinstalled VM images (thanks for that, by the way).


So there will be no impact on you at all, except that /etc/services will 
have a lot more services.  As Alan said, Python and XML will only be 
added to the developer workflow.



  |As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
  |can't easily handle things like IANA's representation of aliases, and \
  |it can't
  |easily format the list in the same order as our current list.  Python \
  |is truly a better choice.

I absolutely fail to see what you mean.  The script (which is in
actual use, mind you) generates the desired output except that
comments get lost, but this could be added upon interest, of
course.  It (or a derivative) would have been a good candidate for
/usr/share/misc/ in elder times i guess, too.


That awk script depends on the formatting of the XML file.  It will 
break if the IANA decides to format it differently.  Granted, this is 
unlikely, but it's possible.


Also, that script would become much more complex if it supported local 
additions and overrides, which are unfortunately necessary in our case.


Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Steffen Nurpmeso]

Alan Somers wrote in :
 |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
 |even after Eric's patch.  His Python script will only need to be run \
 |whenever IANA 
 |updates its database, and the results will be checked into source contro\
 |l.  So for a normal user, there is no change to "make buildworld && make 
 |installworld".

I cannot, unfortunately.  I use binary updates and even
preinstalled VM images (thanks for that, by the way).

 |As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
 |can't easily handle things like IANA's representation of aliases, and \
 |it can't 
 |easily format the list in the same order as our current list.  Python \
 |is truly a better choice.

I absolutely fail to see what you mean.  The script (which is in
actual use, mind you) generates the desired output except that
comments get lost, but this could be added upon interest, of
course.  It (or a derivative) would have been a good candidate for
/usr/share/misc/ in elder times i guess, too.

 |-Alan

Ciao.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Alan Somers]

Don't worry Steffen.  Python won't be a build requirement for FreeBSD even
after Eric's patch.  His Python script will only need to be run whenever
IANA updates its database, and the results will be checked into source
control.  So for a normal user, there is no change to "make buildworld &&
make installworld".

As for Python vs Awk, I too tried to do this with Awk.  However, Awk can't
easily handle things like IANA's representation of aliases, and it can't
easily format the list in the same order as our current list.  Python is
truly a better choice.

-Alan

On Tue, Sep 11, 2018 at 8:19 AM Steffen Nurpmeso  wrote:

> Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792...@vangyzen.net
> >:
>  |On 9/10/18 12:04 PM, Eric van Gyzen wrote:
>  |> Would anyone like to review this change to generate /etc/services from
>  |> the IANA registry?
>  |>
>  |>  https://reviews.freebsd.org/D17106
>  |
>  |If that review made your browser unhappy, try this one instead:
>
> Yes it did.
>
>  | https://reviews.freebsd.org/D17115
>
> I mean, i have nothing to do with FreeBSD except that i use it
> since 4.7 (though some yours only indirectly as Mac OS X), and
> i am in opposition to quite some directions taken, but who am i,
> that is ok, i have a very narrow use case.  But this is one of the
> things i really do not understand, bringing XML and Python stuff
> needlessly into FreeBSD seems very odd.  For example, ArchLinux
> and CRUX Linux use a simple portable awk script to generate
> services and protocols, and all you need to count the number of
> services is a normal Unix pipeline which strips comments and then
> calls wc -l.  I'll paste the script below this.  Thank you.
> And ciao already here
>
> #!/bin/sh -
> #@ Update protocols and services from IANA.
> #@ Taken from ArchLinux script written by Gaetan Bisson.  Adjusted for
> CRUX.
>
> awk=awk
> curl=curl
> url_pn=
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
> url_snpn=https://www.iana.org/assignments/service-names-port-numbers/\
> service-names-port-numbers.xml
> 
>
> datetime=`date +'%FT%T%z'`
>
> download() {
>echo 'Downloading protocols'
>${curl} -o protocols.xml ${url_pn}
>[ ${?} -eq 0 ] || exit 20
>echo 'Downloading services'
>${curl} -o services.xml ${url_snpn}
>[ ${?} -eq 0 ] || exit 21
> }
>
> process() {
>echo 'Processing protocols'
>${awk} -F "[<>]" -v URL="${url_pn}" -v DT="${datetime}" '
>   BEGIN{
>  print "# /etc/protocols, created " DT
>  print "# Source: " URL
>   }
>   /   /   /   /<\/record/ && n && v != ""{
>  printf "%-12s %3i %s\n", tolower(n), v, n
>   }
>' < protocols.xml > protocols.new
>[ ${?} -eq 0 ] || exit 30
>
>echo 'Processing services'
>${awk} -F "[<>]" -v URL="${url_snpn}" -v DT="${datetime}" '
>   BEGIN{
>  print "# /etc/services, created " DT
>  print "# Source: " URL
>   }
>   /   /   /   /   /Unassigned/ || /Reserved/ || /historic/ {c = 1}
>   /<\/record/ && n && u && p && !c{
>  printf "%-15s %5i/%s\n", n, u, p
>   }
>' < services.xml > services.new
>[ ${?} -eq 0 ] || exit 31
> }
>
> update() {
>mv protocols.new protocols
>[ ${?} -eq 0 ] || exit 40
>mv services.new services
>[ ${?} -eq 0 ] || exit 41
>rm -f protocols.xml services.xml
> }
>
> download
> process
> #update
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Steffen Nurpmeso]

Eric van Gyzen wrote in <59cd421e-f5d4-855a-83ec-65726f792...@vangyzen.net>:
 |On 9/10/18 12:04 PM, Eric van Gyzen wrote:
 |> Would anyone like to review this change to generate /etc/services from 
 |> the IANA registry?
 |> 
 |>  https://reviews.freebsd.org/D17106
 |
 |If that review made your browser unhappy, try this one instead:

Yes it did.

 | https://reviews.freebsd.org/D17115

I mean, i have nothing to do with FreeBSD except that i use it
since 4.7 (though some yours only indirectly as Mac OS X), and
i am in opposition to quite some directions taken, but who am i,
that is ok, i have a very narrow use case.  But this is one of the
things i really do not understand, bringing XML and Python stuff
needlessly into FreeBSD seems very odd.  For example, ArchLinux
and CRUX Linux use a simple portable awk script to generate
services and protocols, and all you need to count the number of
services is a normal Unix pipeline which strips comments and then
calls wc -l.  I'll paste the script below this.  Thank you.
And ciao already here

#!/bin/sh -
#@ Update protocols and services from IANA.
#@ Taken from ArchLinux script written by Gaetan Bisson.  Adjusted for CRUX.

awk=awk
curl=curl
url_pn=https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
url_snpn=https://www.iana.org/assignments/service-names-port-numbers/\
service-names-port-numbers.xml

datetime=`date +'%FT%T%z'`

download() {
   echo 'Downloading protocols'
   ${curl} -o protocols.xml ${url_pn}
   [ ${?} -eq 0 ] || exit 20
   echo 'Downloading services'
   ${curl} -o services.xml ${url_snpn}
   [ ${?} -eq 0 ] || exit 21
}

process() {
   echo 'Processing protocols'
   ${awk} -F "[<>]" -v URL="${url_pn}" -v DT="${datetime}" '
  BEGIN{
 print "# /etc/protocols, created " DT
 print "# Source: " URL
  }
  / protocols.new
   [ ${?} -eq 0 ] || exit 30

   echo 'Processing services'
   ${awk} -F "[<>]" -v URL="${url_snpn}" -v DT="${datetime}" '
  BEGIN{
 print "# /etc/services, created " DT
 print "# Source: " URL
  }
  / services.new
   [ ${?} -eq 0 ] || exit 31
}

update() {
   mv protocols.new protocols
   [ ${?} -eq 0 ] || exit 40
   mv services.new services
   [ ${?} -eq 0 ] || exit 41
   rm -f protocols.xml services.xml
}

download
process
#update

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Request for Review: Generate /etc/services from the IANA registry

[Eric van Gyzen]

On 9/10/18 12:04 PM, Eric van Gyzen wrote:
Would anyone like to review this change to generate /etc/services from 
the IANA registry?


 https://reviews.freebsd.org/D17106


If that review made your browser unhappy, try this one instead:

https://reviews.freebsd.org/D17115

Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Request for Review: Generate /etc/services from the IANA registry

[Eric van Gyzen]

Would anyone like to review this change to generate /etc/services from 
the IANA registry?


https://reviews.freebsd.org/D17106

Thanks,

Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Request for review] Profiling the FreeBSD kernel boot

[Colin Percival]

On 12/22/17 09:08, Mark Johnston wrote:
> On Fri, Dec 22, 2017 at 09:44:46AM +, Colin Percival wrote:
>> For the past few months I've been working on code for profiling the FreeBSD
>> "kernel boot", i.e., everything between when kernel code starts running and
>> when we first enter userland as init(8).  This is not trivial since it's
>> impossible to use tools like dtrace to monitor things prior to when said
>> tools are running.
> 
> In the case of DTrace, this isn't quite true. We support so-called
> boot-time DTrace on x86. The caveat is that we can only start tracing
> after the SI_SUB_DTRACE_ANON sysinit has been executed. That sysinit
> can't come earlier than SI_SUB_SMP, since it needs to be able to measure
> TSC skew between CPUs in order to initialize DTrace's high-resolution
> timer.

Right.  Also, even aside from details like measuring the TSC skew between
CPUs, DTrace needs things like traps, memory allocation, and mutexes, none
of which exist when we enter hammer_time (or any of the other MD startup
code).

What I meant is that it's impossible to use DTrace to monitor things which
happened prior to when the DTrace *kernel bits* are initialized.

> I don't think boot-time DTrace is quite what you want for this exercise,
> but it does come in handy sometimes.

Absolutely.  And for a long time I considered trying to splice together
a basic profiling mechanism for pre-DTrace-initialization with using DTrace
from when it's ready onwards... but I decided that it would be easier at
least to start with to simply use a single mechanism throughout.

> In case it's of interest: to use boot-time DTrace, invoke dtrace(1) as
> you normally would and add -A. Rather than starting to trace, dtrace(1)
> will save a representation of the D script to a file which gets read by
> the loader during the next boot. The results of the trace can be fetched
> with "dtrace -a". For instance, to print the amount of time elapsed in
> microseconds during each vprintf() call, along with a stack: [...]

Thanks for the example!  I think it's very likely that I'll make use of
boot-time DTrace for tracking down some of the performance warts I've found
-- the ones which happen after DTrace is initialized, that is.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Request for review] Profiling the FreeBSD kernel boot

[Mark Johnston]

On Fri, Dec 22, 2017 at 09:44:46AM +, Colin Percival wrote:
> Hi everyone,
> 
> For the past few months I've been working on code for profiling the FreeBSD
> "kernel boot", i.e., everything between when kernel code starts running and
> when we first enter userland as init(8).  This is not trivial since it's
> impossible to use tools like dtrace to monitor things prior to when said
> tools are running.

In the case of DTrace, this isn't quite true. We support so-called
boot-time DTrace on x86. The caveat is that we can only start tracing
after the SI_SUB_DTRACE_ANON sysinit has been executed. That sysinit
can't come earlier than SI_SUB_SMP, since it needs to be able to measure
TSC skew between CPUs in order to initialize DTrace's high-resolution
timer.

I don't think boot-time DTrace is quite what you want for this exercise,
but it does come in handy sometimes.

In case it's of interest: to use boot-time DTrace, invoke dtrace(1) as
you normally would and add -A. Rather than starting to trace, dtrace(1)
will save a representation of the D script to a file which gets read by
the loader during the next boot. The results of the trace can be fetched
with "dtrace -a". For instance, to print the amount of time elapsed in
microseconds during each vprintf() call, along with a stack:

# dtrace -A -n 'fbt::vprintf:entry {self->ts = timestamp;}
fbt::vprintf:return /self->ts/
{
printf("%d", (timestamp - self->ts) / 1000);
self->ts = 0;
stack();
}'
...

# dtrace -a -e
CPU IDFUNCTION:NAME 

  0  17161   vprintf:return 419 
 
  kernel`printf+0x43 
  kernel`randomdev_modevent+0x26   
  kernel`module_register_init+0xc0 
  kernel`mi_startup+0x9c

  kernel`0x8028656c
  ...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Request for review] Profiling the FreeBSD kernel boot

[blubee blubeeme]

On Fri, Dec 22, 2017 at 5:44 PM, Colin Percival 
wrote:

> Hi everyone,
>
> For the past few months I've been working on code for profiling the FreeBSD
> "kernel boot", i.e., everything between when kernel code starts running and
> when we first enter userland as init(8).  This is not trivial since it's
> impossible to use tools like dtrace to monitor things prior to when said
> tools are running.  The goal of this exercise is to help me track down the
> places where we're wasting time during the boot, and then to fix them.
>
> The approach I've taken is to add some macros -- most notably TSENTER() and
> TSEXIT() -- which by default compile to nothing, but if the TSLOG kernel
> option is enabled they compile to code which logs the cycle count (e.g., on
> x86 the value from the RDTSC instruction) along with some other data (in
> the
> case of TSENTER and TSEXIT, the fact that we're entering/exiting a
> function).
> This can then be dumped via a sysctl (debug.tslog) and processed in
> userland
> to convert function entries/exits into stacks and to visualize the time
> spent
> in the boot process.
>
> Two examples:
>
> A flame chart of my laptop booting HEAD:
> http://www.daemonology.net/timestamping/tslog-laptop.svg
>
> A flame chart of an EC2 c5.4xlarge instance booting 11.1-RELEASE:
> http://www.daemonology.net/timestamping/tslog-c5.4xlarge.svg
>
> The patches (10 of them, to be applied in order), userland scripts, and
> very
> brief usage instructions are at:
> http://www.daemonology.net/timestamping/tslog.tgz
>
> I hope to commit the patches in the next week, since I'm planning on
> writing
> a paper to submit to AsiaBSDCon (which has a deadline of December 31st); so
> if anyone has interest/time to look at this in the near future (I mean,
> it's
> not like anyone is going to be busy this weekend, right?) I'd love to have
> some feedback before it goes into the tree.
>
> --
> Colin Percival
> Security Officer Emeritus, FreeBSD | The power to serve
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
I've gotta say  nice work with the tracing.
Hopefully your talk gets accepted, i'd love to hear it.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Request for review] Profiling the FreeBSD kernel boot

[Hans Petter Selasky]

On 12/22/17 10:44, Colin Percival wrote:

track down the
places where we're wasting time during the boot, and then to fix them.


Hi,

The USB stack will try to enumerate all USB controllers simultaneously.

DELAY() is frequently a problem having to wait for chips to reset during 
enumeration as you probably know. Getting timers enumerated early on 
allows to sleep instead of spin, also saving CPU usage during boot.


I'm not sure if switching on too many PCI devices at the same time can 
cause any power issues. At least USB HUBs have an own delay per port it 
needs to wait until power is turned on.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Request for review] Profiling the FreeBSD kernel boot

[Colin Percival]

Hi everyone,

For the past few months I've been working on code for profiling the FreeBSD
"kernel boot", i.e., everything between when kernel code starts running and
when we first enter userland as init(8).  This is not trivial since it's
impossible to use tools like dtrace to monitor things prior to when said
tools are running.  The goal of this exercise is to help me track down the
places where we're wasting time during the boot, and then to fix them.

The approach I've taken is to add some macros -- most notably TSENTER() and
TSEXIT() -- which by default compile to nothing, but if the TSLOG kernel
option is enabled they compile to code which logs the cycle count (e.g., on
x86 the value from the RDTSC instruction) along with some other data (in the
case of TSENTER and TSEXIT, the fact that we're entering/exiting a function).
This can then be dumped via a sysctl (debug.tslog) and processed in userland
to convert function entries/exits into stacks and to visualize the time spent
in the boot process.

Two examples:

A flame chart of my laptop booting HEAD:
http://www.daemonology.net/timestamping/tslog-laptop.svg

A flame chart of an EC2 c5.4xlarge instance booting 11.1-RELEASE:
http://www.daemonology.net/timestamping/tslog-c5.4xlarge.svg

The patches (10 of them, to be applied in order), userland scripts, and very
brief usage instructions are at:
http://www.daemonology.net/timestamping/tslog.tgz

I hope to commit the patches in the next week, since I'm planning on writing
a paper to submit to AsiaBSDCon (which has a deadline of December 31st); so
if anyone has interest/time to look at this in the near future (I mean, it's
not like anyone is going to be busy this weekend, right?) I'd love to have
some feedback before it goes into the tree.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Request for review] loader changes

[Andrey V. Elsukov]

Hi, All.

It's been a long ago, when i published my patches first time.
And it seems, there is no one who is against or wants suggest something.
So I'm asking for review, and I want start merge changes at the end of week.
Patches are here: http://people.freebsd.org/~ae/bootcode/

full.diff:
The full diff, except tools.

tools.diff:
A small test program bootparttest. It uses sys/boot/common/part.c to
taste GEOM provider or disk image in the similar way, how loader does.

common.diff:
Changes to the common code. This code is used with many architectures and 
libraries.

* common/Makefile.inc
  added LOADER_NO_DISK_SUPPORT knob to disable build common code related to 
disks and
  partitions. By default GPT and MBR support are enabled, LOADER_NO_GPT_SUPPORT 
and
  LOADER_NO_MBR_SUPPORT can disable they.

* common/part.c
  common/part.h
  these files are new. They contains partition tables related code. Several 
words about API:
  Partition table described with opaque type struct ptable, partition entries 
with
  struct ptable_entry {
uint64_tstart;
uint64_tend;
int index;
enum partition_type type;
  };

  The partition tables detection occurs when ptable_open() is called. This 
function takes
  as arguments the number of disk sectors, sector size and pointer to the 
callback
  function, that is know how to read from the disk.
  The ptable_close() function releases allocated resources.
  The ptable_gettype() functions returns the type of partition table.
  The ptable_getpart() functions returns information about specified partition.
  The ptable_iterate() functions calls a callback function for each partition 
in the table.
  The parttype2str() converts partition type to the string.

  The following partition tables are supported: BSD label, GPT, MBR, EBR and 
VTOC8.

* common/disk.c
  common/disk.h
  These files have been changed and they use new API to work with partitions. 
Also now
  they provide new disk API to the devsw disk drivers: disk_open(), 
disk_close(),
  disk_print(), disk_fmtdev() and disk_parsedev().

i386.diff:
Changes related to the i386 architecture:

* i386/libi386/devicename.c
  Use disk_fmtdev() and disk_parsedev() functions from the common code.

* i386/libi386/biosdisk.c
  The disk driver was rewritten to use new disk API. To the devsw ioctl handler 
was added.
  It handles DIOCGSECTORSIZE and DIOCGMEDIASIZE ioctls.

* i386/libi386/libi386.h
  The offset field was added to the i386_devdesc.d_kind.biosdisk structure.

* i386/libi386/Makefile
  removed unneeded flag.

* i386/pmbr/pmbr.s
  Added secondary GPT support.

* i386/loader/main.c
  ZFS probing simplified.

* i386/loader/Makefile
  removed unneeded flag.

userboot.diff:
The disk driver and sample program updated according to the changes in the 
disk.c.
Also new diskioctl callback added.

uboot.diff:
The disk driver was rewritten to use new disk API.

arm.diff:
powerpc.diff:
Added LOADER_NO_DISK_SUPPORT handling to be able build uboot with or without 
disk support.

zfs.diff:
Use new partitions API to probe all ZFS partitions in the GPT and BSD partition 
tables.

So, if there will not any opinions against these APIs and patches I will start
commit. The first step will be common and userboot code, then - i386 and zfs 
parts.

-- 
WBR, Andrey V. Elsukov




signature.asc
Description: OpenPGP digital signature

Re: Request for review/testing: switching the default installer

[Gerrit Kühn]

On Fri, 4 Mar 2011 12:24:20 -0800 Freddie Cash fjwc...@gmail.com wrote
about Re: Request for review/testing: switching the default installer:

FC Or, does anyone have instructions on how to convert the ISO images
FC into memstick images?  Preferably using a Linux station, not a FreeBSD
FC station.

I use unetbootin (http://unetbootin.sourceforge.net/) to create usb
install media from iso images. Works for me.


cu
  Gerrit
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Freddie Cash]

On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn
nwhiteh...@freebsd.org wrote:
 BSDinstall has acquired at this point its final form (prior to a future
 merge with pc-sysinstall), and I believe is ready to replace sysinstall on
 the 9.0 snapshot ISOs. Barring any objections, I would like to pull this
 switch 2 weeks from today, on the 14th of March.
snip
 Bug reports would be very appreciated at this time. There are three known
 bugs currently, which will be fixed soon, so please don't report these:
 error reporting is not graceful if there are no writable disks in the
 system, you must select at least one optional component, and the doc build
 is not currently connected to the releases.
snip

After much finnaggling and gnashing of teeth around hardware (not
related to installer), I have managed to get a bootable 9-CURRENT
image with BSDInstall, and used it to get a bootable install of
FreeBSD 9-CURRENT.  :)

Here are my thought and experiences using the new installer.

Things I really like:
  - that the install CD is a LiveCD with a fully functional system;
while it won't replace a Frenzy CD, it's very close
  - very streamlined install without a lot of extra fluff that just
gets skipped anyway (like everything underneath Standard in the first
sysinstall screen)
  - the ability to use features like GPT, gmirror, zfs right from the get-go
  - the ability to drop to a fully functional shell at various stages
of the install, with access to proper man pages

Things that irritated me:
  - when you drop to a shell from the disk editor screen, it lists the
instructions at the top, but then never repeats them ever again
  - if you get lost in the disk editor shell and type exit to get
back to the disk editor ... it thinks you are finished partitioning
and carries on with the install, which then errors out due to no
writable filesystems, requiring you to restart the entire process
  - the disk editor is very limited, especially in its error handling;
I found myself stuck in a loop trying to exit the screen without a /
filesystem listed, but I was doing everything from the shell
  - screen flips between a nice blue background (the curses
interface?) and a black background (running shell commands?) which is
quite jarring and slightly confusing;
  - screen elements go from nicely centred (curses interface?) and
then jump to the top-left corner of the screen (shell commands?) which
is also quite jarring and slightly confusing

The last two may be limitations in the curses setup?  But it would be
nice if shell command I/O could be centred like the rest, and if the
background could remain a single colour.  Not huge issues, just things
that irritated me.  :)

Overall, I am quite impressed with the new installer, as it is *just*
an installer and not a system configuration creator (or breaker) like
sysinstall.

Now that I understand the new world order of GPT-based partitioning
and booting, I think I'm going to like FreeBSD 9.0 a heck of a lot.

... off to play with dedupe and other ZFSv28 goodies ...

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Nathan Whitehorn]

On 03/07/11 14:14, Freddie Cash wrote:

On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn
nwhiteh...@freebsd.org  wrote:

BSDinstall has acquired at this point its final form (prior to a future
merge with pc-sysinstall), and I believe is ready to replace sysinstall on
the 9.0 snapshot ISOs. Barring any objections, I would like to pull this
switch 2 weeks from today, on the 14th of March.

snip

Bug reports would be very appreciated at this time. There are three known
bugs currently, which will be fixed soon, so please don't report these:
error reporting is not graceful if there are no writable disks in the
system, you must select at least one optional component, and the doc build
is not currently connected to the releases.

snip

After much finnaggling and gnashing of teeth around hardware (not
related to installer), I have managed to get a bootable 9-CURRENT
image with BSDInstall, and used it to get a bootable install of
FreeBSD 9-CURRENT.  :)


Thanks for testing, and sympathies for the hardware trouble!

Here are my thought and experiences using the new installer.

Things I really like:
   - that the install CD is a LiveCD with a fully functional system;
while it won't replace a Frenzy CD, it's very close
   - very streamlined install without a lot of extra fluff that just
gets skipped anyway (like everything underneath Standard in the first
sysinstall screen)
   - the ability to use features like GPT, gmirror, zfs right from the get-go
   - the ability to drop to a fully functional shell at various stages
of the install, with access to proper man pages

Things that irritated me:
   - when you drop to a shell from the disk editor screen, it lists the
instructions at the top, but then never repeats them ever again


Can you suggest a better way to do this? In other words, when and in 
what circumstances would you want to see them again?



   - if you get lost in the disk editor shell and type exit to get
back to the disk editor ... it thinks you are finished partitioning
and carries on with the install, which then errors out due to no
writable filesystems, requiring you to restart the entire process


This is bad. I can modify it to check if a filesystem has been mounted 
at /mnt, and maybe if the fstab file exists and restart the disk editor 
menu if they have not.



   - the disk editor is very limited, especially in its error handling;
I found myself stuck in a loop trying to exit the screen without a /
filesystem listed, but I was doing everything from the shell


That's a clear bug. It should probably only validate the setup if 'Save' 
is selected. The issue of whether it should allow you to save without 
defining a / partition when invoked from a shell is a more complicated 
one, and one I'll have to think about (suggestions welcome).



   - screen flips between a nice blue background (the curses
interface?) and a black background (running shell commands?) which is
quite jarring and slightly confusing;
   - screen elements go from nicely centred (curses interface?) and
then jump to the top-left corner of the screen (shell commands?) which
is also quite jarring and slightly confusing


Yes, this should be prettified. It's running a few things (passwd, 
adduser) in a chroot, and I figured getting things working there was 
more important than making them pretty for now.



The last two may be limitations in the curses setup?  But it would be
nice if shell command I/O could be centred like the rest, and if the
background could remain a single colour.  Not huge issues, just things
that irritated me.  :)

Overall, I am quite impressed with the new installer, as it is *just*
an installer and not a system configuration creator (or breaker) like
sysinstall.

Now that I understand the new world order of GPT-based partitioning
and booting, I think I'm going to like FreeBSD 9.0 a heck of a lot.

... off to play with dedupe and other ZFSv28 goodies ...


Thanks!
-Nathan

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Freddie Cash]

On Mon, Mar 7, 2011 at 4:56 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote:
 On 03/07/11 14:14, Freddie Cash wrote:
 Things that irritated me:
   - when you drop to a shell from the disk editor screen, it lists the
 instructions at the top, but then never repeats them ever again

 Can you suggest a better way to do this? In other words, when and in what
 circumstances would you want to see them again?

It follows along with the next item, so I'll address them both below.

   - if you get lost in the disk editor shell and type exit to get
 back to the disk editor ... it thinks you are finished partitioning
 and carries on with the install, which then errors out due to no
 writable filesystems, requiring you to restart the entire process

 This is bad. I can modify it to check if a filesystem has been mounted at
 /mnt, and maybe if the fstab file exists and restart the disk editor menu if
 they have not.

If something like the above is done, then the first item above is also
handled.  :)

As in, if you forget the instructions, just exit the shell to go back
to the disk editor, which then complains you don't have a mounted
filesystem to install to, and then you can drop back to the shell.

Maybe loop back to the beginning of the disk editor, where it asks you
if you want to do it Guided, Manual, or Shell?  Or something like
that.

Something needs to go here to check for a mounted, writable
filesystem to install to.  :)

On the flip side, the entire install process is short enough that it's
not too onerous to restart it.

   - the disk editor is very limited, especially in its error handling;
 I found myself stuck in a loop trying to exit the screen without a /
 filesystem listed, but I was doing everything from the shell

 That's a clear bug. It should probably only validate the setup if 'Save' is
 selected. The issue of whether it should allow you to save without defining
 a / partition when invoked from a shell is a more complicated one, and one
 I'll have to think about (suggestions welcome).

I don't recall there being a Save option, but maybe I skipped over it
and just went to Exit.  I'll have to look at this screen again.  Using
Save probably would have helpded.  :)

   - screen flips between a nice blue background (the curses
 interface?) and a black background (running shell commands?) which is
 quite jarring and slightly confusing;
   - screen elements go from nicely centred (curses interface?) and
 then jump to the top-left corner of the screen (shell commands?) which
 is also quite jarring and slightly confusing

 Yes, this should be prettified. It's running a few things (passwd, adduser)
 in a chroot, and I figured getting things working there was more important
 than making them pretty for now.

It's a minor nit, as sysinstall does the same.  Maybe there's a way to
use text input fields (like the DHCP screens, and adduser screens from
sysinstall), then run the commands in the background, and just show
error/success messages?  [shrug] I know nothing about curses
programming.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Nathan Whitehorn]

On 03/07/11 19:27, Freddie Cash wrote:

On Mon, Mar 7, 2011 at 4:56 PM, Nathan Whitehornnwhiteh...@freebsd.org  wrote:

On 03/07/11 14:14, Freddie Cash wrote:

Things that irritated me:
   - when you drop to a shell from the disk editor screen, it lists the
instructions at the top, but then never repeats them ever again

Can you suggest a better way to do this? In other words, when and in what
circumstances would you want to see them again?

It follows along with the next item, so I'll address them both below.


   - if you get lost in the disk editor shell and type exit to get
back to the disk editor ... it thinks you are finished partitioning
and carries on with the install, which then errors out due to no
writable filesystems, requiring you to restart the entire process

This is bad. I can modify it to check if a filesystem has been mounted at
/mnt, and maybe if the fstab file exists and restart the disk editor menu if
they have not.

If something like the above is done, then the first item above is also
handled.  :)

As in, if you forget the instructions, just exit the shell to go back
to the disk editor, which then complains you don't have a mounted
filesystem to install to, and then you can drop back to the shell.

Maybe loop back to the beginning of the disk editor, where it asks you
if you want to do it Guided, Manual, or Shell?  Or something like
that.


The Guided, Manual, Shell is what I meant by disk editor menu, so I 
agree with you entirely :)



Something needs to go here to check for a mounted, writable
filesystem to install to.  :)

On the flip side, the entire install process is short enough that it's
not too onerous to restart it.


   - the disk editor is very limited, especially in its error handling;
I found myself stuck in a loop trying to exit the screen without a /
filesystem listed, but I was doing everything from the shell

That's a clear bug. It should probably only validate the setup if 'Save' is
selected. The issue of whether it should allow you to save without defining
a / partition when invoked from a shell is a more complicated one, and one
I'll have to think about (suggestions welcome).

I don't recall there being a Save option, but maybe I skipped over it
and just went to Exit.  I'll have to look at this screen again.  Using
Save probably would have helpded.  :)


If you press Exit, it asks whether you want to Save, Abort, or Cancel. 
Abort exits the partitioner without making changes. I just modified this 
so that it will only try to validate the disk setup if you press Save -- 
you don't need a valid setup if you are bailing on the partitioner, 
after all.



   - screen flips between a nice blue background (the curses
interface?) and a black background (running shell commands?) which is
quite jarring and slightly confusing;
   - screen elements go from nicely centred (curses interface?) and
then jump to the top-left corner of the screen (shell commands?) which
is also quite jarring and slightly confusing

Yes, this should be prettified. It's running a few things (passwd, adduser)
in a chroot, and I figured getting things working there was more important
than making them pretty for now.

It's a minor nit, as sysinstall does the same.  Maybe there's a way to
use text input fields (like the DHCP screens, and adduser screens from
sysinstall), then run the commands in the background, and just show
error/success messages?  [shrug] I know nothing about curses
programming.  :)


Yeah, I need to find time/a good way to do this (or someone else can: 
patches are always welcome). Text fields would work well, and I think 
even just making the banner at the top of the screen blue would help.

-Nathan

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Freddie Cash]

On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn
nwhiteh...@freebsd.org wrote:
 BSDinstall has acquired at this point its final form (prior to a future
 merge with pc-sysinstall), and I believe is ready to replace sysinstall on
 the 9.0 snapshot ISOs. Barring any objections, I would like to pull this
 switch 2 weeks from today, on the 14th of March.

 A patch to the release infrastructure code can be found here (make release
 must be run with Makefile.bsdinstall using this patch to get non-sysinstall
 media):
 http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff

 Test ISOs for amd64 and i386 can be found here:
 http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2
 http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2

 More recent test ISOs, as well as ones for other architectures, may be
 available at:
 http://wiki.freebsd.org/BSDInstall

Any chance of a memstick.img version being made available?

Or, does anyone have instructions on how to convert the ISO images
into memstick images?  Preferably using a Linux station, not a FreeBSD
station.

I have a beautiful 24-drive system here just crying out for testing
9-CURRENT and ZFSv28, but it doesn't have any bootable media except
USB sticks.  And the 2011-01-* memstick snapshot of 9-CURRENT fails
with can't create device node in /dev errors when trying to newfs
the CompactFlash disk that will be /.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Vincent Hoffman]

On 04/03/2011 20:24, Freddie Cash wrote:
 On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn
 nwhiteh...@freebsd.org wrote:
 BSDinstall has acquired at this point its final form (prior to a future
 merge with pc-sysinstall), and I believe is ready to replace sysinstall on
 the 9.0 snapshot ISOs. Barring any objections, I would like to pull this
 switch 2 weeks from today, on the 14th of March.

 A patch to the release infrastructure code can be found here (make release
 must be run with Makefile.bsdinstall using this patch to get non-sysinstall
 media):
 http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff

 Test ISOs for amd64 and i386 can be found here:
 http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2
 http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2

 More recent test ISOs, as well as ones for other architectures, may be
 available at:
 http://wiki.freebsd.org/BSDInstall
 Any chance of a memstick.img version being made available?

 Or, does anyone have instructions on how to convert the ISO images
 into memstick images?  Preferably using a Linux station, not a FreeBSD
 station.

 I have a beautiful 24-drive system here just crying out for testing
 9-CURRENT and ZFSv28, but it doesn't have any bootable media except
 USB sticks.  And the 2011-01-* memstick snapshot of 9-CURRENT fails
 with can't create device node in /dev errors when trying to newfs
 the CompactFlash disk that will be /.

Its always worth having a go with the images from
http://pub.allbsd.org/FreeBSD-snapshots
http://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.0-HEAD-20110304-JPSNAP/cdrom/FreeBSD-9.0-HEAD-20110304-JPSNAP-amd64-amd64-memstick.img
for example.

Vince
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[TAKAHASHI Yoshihiro]

In article 4d6e6c43.4010...@freebsd.org
Nathan Whitehorn nwhiteh...@freebsd.org writes:

 Do you have a plan to add a floppy support as boot device?  Pc98
 machines which can boot from CD-ROM are very limited.  So we usually
 use FD for boot media to install.
 
 No, I hadn't thought about this. If there aren't any machines you care
 about that don't have a CD drive at all, we could try a
 CD-bootloader-on-a-floppy as a solution. I think a totally floppy
 based install would be very difficult to arrange, however.

The boot-only-floppy image is very useful for us.

---
TAKAHASHI Yoshihiro n...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Paul Schenkeveld]

On Wed, Mar 02, 2011 at 09:36:58AM -0600, Nathan Whitehorn wrote:
 On 02/28/11 09:20, John Baldwin wrote:
  On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote:
  There are some changes to the distribution format involved in this
  patch, which are outlined below, and about which I would also appreciate
  feedback:
  - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall
  I would at least like to have src split up into two pieces:
 
  1) would be equivalent of sbase and ssys of old distributions, so you could
  choose to just install kernel sources along with the top-level Makefile bits
  to build kernels.  I commonly install this subset on production machines so 
  I
  can install a custom kernel in a pinch.
 
  2) would be everything else in the source tree.
 
 This is a little bit tricky, since it involves inter-distribution 
 dependencies which don't currently exist (e.g. you need sbase for ssys 
 to be useful, and for severythingelse to be useful). I suppose that the 
 top-level Makefile bits are small and could end up in both archives, 
 where one can overwrite the other with the same thing. Would that solve 
 your problem?
 -Nathan

Why not put the toplevel Makefiles, README and perhaps COPYRIGHT and
MAINTAINERS file into base?  This way there are no inter-dependencies
between src parts, /usr/src will consume only a modest bit of space
in base but documents wat ont would be able to do is sbase/ssys were
installed.

Regards,

Paul Schenkeveld
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Baptiste Daroussin]

2011/3/3 Paul Schenkeveld free...@psconsult.nl:
 On Wed, Mar 02, 2011 at 09:36:58AM -0600, Nathan Whitehorn wrote:
 On 02/28/11 09:20, John Baldwin wrote:
  On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote:
  There are some changes to the distribution format involved in this
  patch, which are outlined below, and about which I would also appreciate
  feedback:
  - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall
  I would at least like to have src split up into two pieces:
 
  1) would be equivalent of sbase and ssys of old distributions, so you could
  choose to just install kernel sources along with the top-level Makefile 
  bits
  to build kernels.  I commonly install this subset on production machines 
  so I
  can install a custom kernel in a pinch.
 
  2) would be everything else in the source tree.

 This is a little bit tricky, since it involves inter-distribution
 dependencies which don't currently exist (e.g. you need sbase for ssys
 to be useful, and for severythingelse to be useful). I suppose that the
 top-level Makefile bits are small and could end up in both archives,
 where one can overwrite the other with the same thing. Would that solve
 your problem?
 -Nathan

 Why not put the toplevel Makefiles, README and perhaps COPYRIGHT and
 MAINTAINERS file into base?  This way there are no inter-dependencies
 between src parts, /usr/src will consume only a modest bit of space
 in base but documents wat ont would be able to do is sbase/ssys were
 installed.

 Regards,

 Paul Schenkeveld
 ___
 freebsd-a...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-arch
 To unsubscribe, send any mail to freebsd-arch-unsubscr...@freebsd.org


While working on this maybe it would be interesting to now use makefs
instead of mkisofs, making installer generation 100% self hosting.

makefs has recently been updating to a recent version from netbsd and
now support iso9660, I already managed to create bootable livecd with
it.

regards,
Bapt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Doug Barton]

On 03/03/2011 02:22, Baptiste Daroussin wrote:


While working on this maybe it would be interesting to now use makefs
instead of mkisofs, making installer generation 100% self hosting.

makefs has recently been updating to a recent version from netbsd and
now support iso9660, I already managed to create bootable livecd with
it.


That would be very nice. There is a weird situation now where you can't 
do ISO creation within 'make release' without also building ports, which 
is a lot of overhead. I solved this problem by scripting the ISO 
creation as a separate step, but it felt kludgy to me.


Another nice improvement in this space would be to be able to select the 
specific ISO(s) that you want to create.



Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Nathan Whitehorn]

On 02/28/11 09:20, John Baldwin wrote:

On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote:

BSDinstall has acquired at this point its final form (prior to a future
merge with pc-sysinstall), and I believe is ready to replace sysinstall
on the 9.0 snapshot ISOs. Barring any objections, I would like to pull
this switch 2 weeks from today, on the 14th of March.

A patch to the release infrastructure code can be found here (make
release must be run with Makefile.bsdinstall using this patch to get
non-sysinstall media):
http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff

Hmm, does your installed world include the pre-built mergemaster database?
That should really be preserved.

It happens here in the old release Makefile:

# Install the system into the various distributions.
release.2:
 cd ${.CURDIR}/..  ${CROSSMAKE} distrib-dirs DESTDIR=${RD}/trees/base
 cd ${.CURDIR}/..  ${CROSSMAKE} ${WORLD_FLAGS} distributeworld \
 DISTDIR=${RD}/trees
 sh ${.CURDIR}/scripts/mm-mtree.sh -F ${CROSSENV} -D
${RD}/trees/base
 touch ${.TARGET}

I use a one-line patch locally to bootstrap etcupdate into the worlds I
package up at work via a similar one-liner.


And this is why sending out patches for review is a good idea. I've 
updated my code to call into this script, though it would be nice if, 
say, make distribution handled this. Thanks for pointing it out.



Test ISOs for amd64 and i386 can be found here:
http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2
http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2

More recent test ISOs, as well as ones for other architectures, may be
available at:
http://wiki.freebsd.org/BSDInstall

Bug reports would be very appreciated at this time. There are three
known bugs currently, which will be fixed soon, so please don't report
these: error reporting is not graceful if there are no writable disks in
the system, you must select at least one optional component, and the doc
build is not currently connected to the releases.

There are some changes to the distribution format involved in this
patch, which are outlined below, and about which I would also appreciate
feedback:
- The src tree is not split up into pieces (e.g. ssbin) as with sysinstall

I would at least like to have src split up into two pieces:

1) would be equivalent of sbase and ssys of old distributions, so you could
choose to just install kernel sources along with the top-level Makefile bits
to build kernels.  I commonly install this subset on production machines so I
can install a custom kernel in a pinch.

2) would be everything else in the source tree.


This is a little bit tricky, since it involves inter-distribution 
dependencies which don't currently exist (e.g. you need sbase for ssys 
to be useful, and for severythingelse to be useful). I suppose that the 
top-level Makefile bits are small and could end up in both archives, 
where one can overwrite the other with the same thing. Would that solve 
your problem?

-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[TAKAHASHI Yoshihiro]

In article 4d6bb5e3.6020...@freebsd.org
Nathan Whitehorn nwhiteh...@freebsd.org writes:

 BSDinstall has acquired at this point its final form (prior to a
 future merge with pc-sysinstall), and I believe is ready to replace
 sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would
 like to pull this switch 2 weeks from today, on the 14th of March.
 
 A patch to the release infrastructure code can be found here (make
 release must be run with Makefile.bsdinstall using this patch to get
 non-sysinstall media):
 http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff

In Makefile.bsdinstall:

+cdrom:
+   echo kernel_options=\-C\  ${DISTDIR}/release/boot/loader.conf
+   sh /usr/src/release/${TARGET}/mkisoimages.sh -b FreeBSD_Install 
${DISTDIR}/release.iso ${DISTDIR}/release
+   rm ${DISTDIR}/release/boot/loader.conf

${TARGET} must be ${TARGET_ARCH} because pc98 and sunv4 don't have
mkisoimages.sh script.


Do you have a plan to add a floppy support as boot device?  Pc98
machines which can boot from CD-ROM are very limited.  So we usually
use FD for boot media to install.

---
TAKAHASHI Yoshihiro n...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Nathan Whitehorn]

On 03/02/11 10:06, TAKAHASHI Yoshihiro wrote:

In article4d6bb5e3.6020...@freebsd.org
Nathan Whitehornnwhiteh...@freebsd.org  writes:


BSDinstall has acquired at this point its final form (prior to a
future merge with pc-sysinstall), and I believe is ready to replace
sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would
like to pull this switch 2 weeks from today, on the 14th of March.

A patch to the release infrastructure code can be found here (make
release must be run with Makefile.bsdinstall using this patch to get
non-sysinstall media):
http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff

In Makefile.bsdinstall:

+cdrom:
+   echo kernel_options=\-C\  ${DISTDIR}/release/boot/loader.conf
+   sh /usr/src/release/${TARGET}/mkisoimages.sh -b FreeBSD_Install 
${DISTDIR}/release.iso ${DISTDIR}/release
+   rm ${DISTDIR}/release/boot/loader.conf

${TARGET} must be ${TARGET_ARCH} because pc98 and sunv4 don't have
mkisoimages.sh script.


I was thinking of just copying the i386/mkisoimages.sh and making the -G 
behavior the default. It seems to me to make more sense to use MACHINE 
than MACHINE_ARCH for this, since pc98 seems to have different 
requirements than i386. We could just copy the sparc64 install script 
for sun4v.

Do you have a plan to add a floppy support as boot device?  Pc98
machines which can boot from CD-ROM are very limited.  So we usually
use FD for boot media to install.


No, I hadn't thought about this. If there aren't any machines you care 
about that don't have a CD drive at all, we could try a 
CD-bootloader-on-a-floppy as a solution. I think a totally floppy based 
install would be very difficult to arrange, however.

-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[John Baldwin]

On Wednesday, March 02, 2011 10:36:58 am Nathan Whitehorn wrote:
 On 02/28/11 09:20, John Baldwin wrote:
  On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote:
  BSDinstall has acquired at this point its final form (prior to a future
  merge with pc-sysinstall), and I believe is ready to replace sysinstall
  on the 9.0 snapshot ISOs. Barring any objections, I would like to pull
  this switch 2 weeks from today, on the 14th of March.
 
  A patch to the release infrastructure code can be found here (make
  release must be run with Makefile.bsdinstall using this patch to get
  non-sysinstall media):
  http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff
  Hmm, does your installed world include the pre-built mergemaster database?
  That should really be preserved.
 
  It happens here in the old release Makefile:
 
  # Install the system into the various distributions.
  release.2:
   cd ${.CURDIR}/..  ${CROSSMAKE} distrib-dirs 
  DESTDIR=${RD}/trees/base
   cd ${.CURDIR}/..  ${CROSSMAKE} ${WORLD_FLAGS} distributeworld \
   DISTDIR=${RD}/trees
   sh ${.CURDIR}/scripts/mm-mtree.sh -F ${CROSSENV} -D
  ${RD}/trees/base
   touch ${.TARGET}
 
  I use a one-line patch locally to bootstrap etcupdate into the worlds I
  package up at work via a similar one-liner.
 
 And this is why sending out patches for review is a good idea. I've 
 updated my code to call into this script, though it would be nice if, 
 say, make distribution handled this. Thanks for pointing it out.
 
  Test ISOs for amd64 and i386 can be found here:
  http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2
  http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2
 
  More recent test ISOs, as well as ones for other architectures, may be
  available at:
  http://wiki.freebsd.org/BSDInstall
 
  Bug reports would be very appreciated at this time. There are three
  known bugs currently, which will be fixed soon, so please don't report
  these: error reporting is not graceful if there are no writable disks in
  the system, you must select at least one optional component, and the doc
  build is not currently connected to the releases.
 
  There are some changes to the distribution format involved in this
  patch, which are outlined below, and about which I would also appreciate
  feedback:
  - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall
  I would at least like to have src split up into two pieces:
 
  1) would be equivalent of sbase and ssys of old distributions, so you could
  choose to just install kernel sources along with the top-level Makefile bits
  to build kernels.  I commonly install this subset on production machines so 
  I
  can install a custom kernel in a pinch.
 
  2) would be everything else in the source tree.
 
 This is a little bit tricky, since it involves inter-distribution 
 dependencies which don't currently exist (e.g. you need sbase for ssys 
 to be useful, and for severythingelse to be useful). I suppose that the 
 top-level Makefile bits are small and could end up in both archives, 
 where one can overwrite the other with the same thing. Would that solve 
 your problem?

Hmm, my thinking is ssys would include sbase, and severythingelse would
require ssys.  That is already true since libc needs syscall.mk from the
kernel sources anyway.  From a user perspective you end up with three
choices: no sources, kernel sources, or all sources.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Request for review/testing: switching the default installer

[Nathan Whitehorn]

BSDinstall has acquired at this point its final form (prior to a future 
merge with pc-sysinstall), and I believe is ready to replace sysinstall 
on the 9.0 snapshot ISOs. Barring any objections, I would like to pull 
this switch 2 weeks from today, on the 14th of March.


A patch to the release infrastructure code can be found here (make 
release must be run with Makefile.bsdinstall using this patch to get 
non-sysinstall media):

http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff

Test ISOs for amd64 and i386 can be found here:
http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2
http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2

More recent test ISOs, as well as ones for other architectures, may be 
available at:

http://wiki.freebsd.org/BSDInstall

Bug reports would be very appreciated at this time. There are three 
known bugs currently, which will be fixed soon, so please don't report 
these: error reporting is not graceful if there are no writable disks in 
the system, you must select at least one optional component, and the doc 
build is not currently connected to the releases.


There are some changes to the distribution format involved in this 
patch, which are outlined below, and about which I would also appreciate 
feedback:

- The src tree is not split up into pieces (e.g. ssbin) as with sysinstall
- Distfiles are not chunked, but are single xz-compressed archives
- There is only one CD image produced, which is always also a live CD
- There are no packages on this CD. There is about 100 MB of free space 
on it right now, so it might make sense to keep it this way and to make 
a separate packages CD/DVD. Removing packages from disc1 also makes 
cross-building release ISOs possible.


Thanks to everyone who has provided testing and feedback over the last 
two months!

-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Bruce Cran]

On Mon, 28 Feb 2011 08:49:07 -0600
Nathan Whitehorn nwhiteh...@freebsd.org wrote:

 - There is only one CD image produced, which is always also a live CD

It would be really useful if a netinstall ISO could be made too -
people still have slow Internet connections where having a bootonly
disc is nice. For example Debian's 35 MB business-card CD is great when
you can only download at 50 kB/s.

-- 
Bruce Cran
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[Nathan Whitehorn]

On 02/28/11 08:56, Bruce Cran wrote:

On Mon, 28 Feb 2011 08:49:07 -0600
Nathan Whitehornnwhiteh...@freebsd.org  wrote:


- There is only one CD image produced, which is always also a live CD

It would be really useful if a netinstall ISO could be made too -
people still have slow Internet connections where having a bootonly
disc is nice. For example Debian's 35 MB business-card CD is great when
you can only download at 50 kB/s.


Yes, I agree. The netinstall stuff is only really useful once the FTP 
mirrors start carrying the new distribution format, so it isn't hooked 
up yet. I've been keeping track of (and minimizing) the tools used by 
the installer, which should help select what things should do on this 
disk and in case we also want to produce some super-minimal TFTP-able 
MFS root in the future.

-Nathan

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request for review/testing: switching the default installer

[John Baldwin]

On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote:
 BSDinstall has acquired at this point its final form (prior to a future 
 merge with pc-sysinstall), and I believe is ready to replace sysinstall 
 on the 9.0 snapshot ISOs. Barring any objections, I would like to pull 
 this switch 2 weeks from today, on the 14th of March.
 
 A patch to the release infrastructure code can be found here (make 
 release must be run with Makefile.bsdinstall using this patch to get 
 non-sysinstall media):
 http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff

Hmm, does your installed world include the pre-built mergemaster database? 
That should really be preserved.

It happens here in the old release Makefile:

# Install the system into the various distributions.
release.2:
cd ${.CURDIR}/..  ${CROSSMAKE} distrib-dirs DESTDIR=${RD}/trees/base
cd ${.CURDIR}/..  ${CROSSMAKE} ${WORLD_FLAGS} distributeworld \
DISTDIR=${RD}/trees
sh ${.CURDIR}/scripts/mm-mtree.sh -F ${CROSSENV} -D 
${RD}/trees/base
touch ${.TARGET}

I use a one-line patch locally to bootstrap etcupdate into the worlds I 
package up at work via a similar one-liner.

 Test ISOs for amd64 and i386 can be found here:
 http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2
 http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2
 
 More recent test ISOs, as well as ones for other architectures, may be 
 available at:
 http://wiki.freebsd.org/BSDInstall
 
 Bug reports would be very appreciated at this time. There are three 
 known bugs currently, which will be fixed soon, so please don't report 
 these: error reporting is not graceful if there are no writable disks in 
 the system, you must select at least one optional component, and the doc 
 build is not currently connected to the releases.
 
 There are some changes to the distribution format involved in this 
 patch, which are outlined below, and about which I would also appreciate 
 feedback:
 - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall

I would at least like to have src split up into two pieces:

1) would be equivalent of sbase and ssys of old distributions, so you could 
choose to just install kernel sources along with the top-level Makefile bits 
to build kernels.  I commonly install this subset on production machines so I 
can install a custom kernel in a pinch.

2) would be everything else in the source tree.

 - Distfiles are not chunked, but are single xz-compressed archives
 - There is only one CD image produced, which is always also a live CD
 - There are no packages on this CD. There is about 100 MB of free space 
 on it right now, so it might make sense to keep it this way and to make 
 a separate packages CD/DVD. Removing packages from disc1 also makes 
 cross-building release ISOs possible.

Packages were always optional on disc1 anyway, but moving them completely off 
is probably ok.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

acpi_ec: request for review and testing

[Andriy Gapon]

FYI: http://article.gmane.org/gmane.os.freebsd.devel.acpi/6440
If you can test and would like to report, please followup to that thread on 
acpi@
mailing list.  Please do not followup to this post.
Thanks!
-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Request for review: kern/45994

[Archie Cobbs]

Could some knowlegable folks review the patch in kern/45994?

http://www.freebsd.org/cgi/query-pr.cgi?pr=45994

Note: I'm talking about the second patch, not the first one.
In the PR the second patch is base64 encoded and not readable.
Here is a decoded version:

http://www.dellroad.org/dropbox/coredump.diff

I'm not expert enough in this area to review it alone, but would
be happy to commit it if other agree it's suitable.

Thanks,
-Archie

__
Archie Cobbs * Packet Design * http://www.packetdesign.com

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

Re: Request for review: kern/45994

[Matthew Dillon]

Well, there are two patches in that PR.  I was not able to unpack
the second mime-encoded diff that implements the NOCORE method, which
is the one I think we should use.  The described methodology is sound,
though.  If someone could email the diff to me I will give it a more
complete lookover.

-Matt

:Could some knowlegable folks review the patch in kern/45994?
:
:http://www.freebsd.org/cgi/query-pr.cgi?pr=45994
:
:Note: I'm talking about the second patch, not the first one.
:In the PR the second patch is base64 encoded and not readable.
:Here is a decoded version:
:
:http://www.dellroad.org/dropbox/coredump.diff
:
:I'm not expert enough in this area to review it alone, but would
:be happy to commit it if other agree it's suitable.
:
:Thanks,
:-Archie
:
:__
:Archie Cobbs * Packet Design * http://www.packetdesign.com

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

Re: Request for review: kern/45994

[Matthew Dillon]

Just call me an idiot.  I'm looking it over now :-)

-Matt

:http://www.dellroad.org/dropbox/coredump.diff
:
:Thanks,
:-Archie

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

Re: Request for review testing of VFS locking patch

[Boris Popov]

On Thu, 19 Sep 2002, Jeff Roberson wrote:

 This patch touches every filesystem.  I have tested with several but I
 would appreciate more extensive testing especially if you use one of the
 lesser used filesystems (ie non ufs).  Please test with WITNESS and
 DEBUG_VFS_LOCKS enabled.  If you find that it drops into the debugger
 please get a back trace and then do the following:

Well, haven't tested it with smbfs, but may point that patch for
nwfs contains two vref()s instead of vgetref().

-- 
Boris Popov
http://rbp.euro.ru


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

Re: Request for review testing of VFS locking patch

[Jeff Roberson]

On Fri, 20 Sep 2002, Boris Popov wrote:

 On Thu, 19 Sep 2002, Jeff Roberson wrote:
 
   Well, haven't tested it with smbfs, but may point that patch for
 nwfs contains two vref()s instead of vgetref().
 

Ah, thanks very much.  (un?)luckily it was in debug code so it would not
have been noticed for a while.  I have updated the patch to reflect this
change as well as three bugs in the nfs locking that phk and I found.

It's at the same place: http://www.chesapeake.net/~jroberson/vfssmp.diff

Thanks,
Jeff


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

Request for review testing of VFS locking patch

[Jeff Roberson]

I have a patch available at
http://www.chesapeake.net/~jroberson/vfssmp.diff that locks the majority
of the vnode fields.  The namecache locking has been omitted from this
patch.  The locking has been specified in vnode.h and all interlock,
syncer, and vn lock usage has been verified.  Any places that are unlocked
now should be marked with mp_fixme's.  

This patch touches every filesystem.  I have tested with several but I
would appreciate more extensive testing especially if you use one of the
lesser used filesystems (ie non ufs).  Please test with WITNESS and
DEBUG_VFS_LOCKS enabled.  If you find that it drops into the debugger
please get a back trace and then do the following:

w vfs_badlock_panic 0
w vfs_badlock_print 0
w vfs_badlock_mutex 0

Currently I know that sendfile() and the UFS snapshot code fail
assertions.

There are many diffs that just switch from explicit mtx ops to using the
new VI_*LOCK macros.  I did this only in places where I actually reviewed
the code.  The remaining direct v_interlock accesses serve as indicators
of behavior that needs to be further verified.  I also have not verified
usage of the mntvnode mtx or the freelist mutex etc.  There may be racees
there.  I did, however, fixup the broken vflush() mntvnode race.

Once this has been commited I will be free to lock the rest of the vnode
and then move on to other filesystem related datastructures.  My goal is
to have the high level VFS and at least some filesystems SMP safe for 5.0.

Any feedback is welcome.

Thanks,
Jeff


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

Request of review: pgrp + session patch

[Seigo Tanimura]

I am going to commit my work for quite a few months on locking a pgrp
and session to -current in two weeks. The patch is at:

http://people.FreeBSD.org/~tanimura/patches/pgrp.diff.gz

This patch has been running quite well on my box with kern.giant.proc
set to zero for more than a month. Could anyone interested please test
the patch?

Comments and suggestions are welcome.

-- 
Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED]

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

Re: Request for review [Re: /bin/ls patch round #2]

[Jun Kuriyama]

Hi keichii,

At 22 Mar 2001 01:00:54 GMT,
Michael C . Wu [EMAIL PROTECTED] wrote:
 | If we're not going to bring in CITRUS, I'd prefer to see runes junked
 
 We(I) will. 

Is there any progress about your porting work?


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
 [EMAIL PROTECTED] // FreeBSD Project

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

Re: Request for review [Re: /bin/ls patch round #2]

[Andrey A. Chernov]

On Wed, Mar 21, 2001 at 12:58:05 +0900, MINOURA Makoto wrote:
 
 | In [EMAIL PROTECTED]
 |  Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] wrote:
 
  Which is still something which needs to be done yes.
 
 Hmmm, I didn't know that... FreeBSD lacks iswprint() etc...
 
 It's..., it's ok, Michael is right, there's no way to do that
 w/o adding some functions to libc.  Ideally we have to
 implement isw*() family though, of course.

I fully agree. wctype.h and isw*() must be implemented first instead of
hacking or using private interface (like runes) in userland program.
It will be easy to implement them over existen ctype mechanism masking
runes with wchar_t. Any takers?

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: Request for review [Re: /bin/ls patch round #2]

[Don Croyle]

"Andrey A. Chernov" [EMAIL PROTECTED] writes:

 I fully agree. wctype.h and isw*() must be implemented first instead of
 hacking or using private interface (like runes) in userland program.
 It will be easy to implement them over existen ctype mechanism masking
 runes with wchar_t. Any takers?

If we're not going to bring in CITRUS, I'd prefer to see runes junked
as an unnecessary layer of abstraction.  Doing so would break
backwards compatibility for locales, but I think we're going to end up
doing that eventually anyway.
-- 
I've always wanted to be a dilettante, but I've never quite been ready
to make the commitment.

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

Re: Request for review [Re: /bin/ls patch round #2]

[Garrett Wollman]

On 21 Mar 2001 13:02:41 +0900, [EMAIL PROTECTED] (MINOURA Makoto) said:

 Sorry I'm not sure but rune API is slightly different
 between 4.4BSD and Plan9, isn't it?

Nobody runs Plan 9, whereas hundreds of thousands of machines run
*BSD.

 Sources of the standard commands are often used as a living
 textbook to other programmers.  They should be as `good' as
 possible, and in my opinion `good' includes `standard-complient'.

You would have to exclude most of the programs in 4.4BSD by that
definition.  There is a reason why interfaces like err(3) and
daemon(3) are included in the standard C library, and the style guide
strongly recommends their usage.

-GAWollman


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

Re: Request for review [Re: /bin/ls patch round #2]

[Andrey A. Chernov]

On Wed, Mar 21, 2001 at 16:19:10 -0500, Garrett Wollman wrote:
 You would have to exclude most of the programs in 4.4BSD by that
 definition.  There is a reason why interfaces like err(3) and
 daemon(3) are included in the standard C library, and the style guide
 strongly recommends their usage.

This particular case is different from what you say. There is no strict
POSIX/ISO C equivalent of functionality you describe, but in case we
discuss it exist. I.e. when two implementations does the same thing,
POSIX/ISO C variant is preferred.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: Request for review [Re: /bin/ls patch round #2]

[Garrett Wollman]

On Thu, 22 Mar 2001 00:26:09 +0300, "Andrey A. Chernov" [EMAIL PROTECTED] said:

 This particular case is different from what you say. There is no strict
 POSIX/ISO C equivalent of functionality you describe, 

Certainly there is.  The daemon(3) function is implemented entirely on
top of POSIX interfaces: fork(), setsid(), chdir(), open(), dup2(),
and close().  It is supplied because many programs which attempt to do
this from scratch get it wrong.  Similarly, err(3) could be entirely
implemented in terms of ISO C primitives: vfprintf(), strerror(), and
exit().  The style guide recommends its use because err() is a simpler
interface, thus harder to get wrong than rolling one's own.  strsep(3)
is another similar example.

 I.e. when two implementations does the same thing, POSIX/ISO C
 variant is preferred.

Erm, no -- the superior version is preferred.  (Something of a
tautology.)  FreeBSD has never been about slavish adherence to
standards; while we prefer to follow relevant standards, if the
standards are broken we do our own thing, and that goes doubly so for
the way we code the standard utilities.  That doesn't mean we
shouldn't implement wctype.h et al, but it does mean that we should
use whichever facilities are cleanest, and easiest to code for and
maintain, rather than those which are specifically blessed by an ISO
working group.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick

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

Re: Request for review [Re: /bin/ls patch round #2]

[Andrey A. Chernov]

On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote:
 On Thu, 22 Mar 2001 00:26:09 +0300, "Andrey A. Chernov" [EMAIL PROTECTED] said:
 
  This particular case is different from what you say. There is no strict
  POSIX/ISO C equivalent of functionality you describe, 
 
 Certainly there is.  The daemon(3) function is implemented entirely on
 top of POSIX interfaces: fork(), setsid(), chdir(), open(), dup2(),
 and close().  It is supplied because many programs which attempt to do
 this from scratch get it wrong.  Similarly, err(3) could be entirely
 implemented in terms of ISO C primitives: vfprintf(), strerror(), and
 exit().  The style guide recommends its use because err() is a simpler
 interface, thus harder to get wrong than rolling one's own.  strsep(3)
 is another similar example.

I mean _strict_ equivalent in more strict sense, i.e. the same amount of
calls needed, the same interface complexity, the same capabilities, etc.

  I.e. when two implementations does the same thing, POSIX/ISO C
  variant is preferred.
 
 Erm, no -- the superior version is preferred.  (Something of a

Since I mean _strict_ equivalent, there can't be superior version by
definition, because it makes equivalent no strict. In case we discuss
equivalent is strict.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: Request for review [Re: /bin/ls patch round #2]

[Andrey A. Chernov]

On Wed, Mar 21, 2001 at 16:39:44 -0500, Garrett Wollman wrote:
 the way we code the standard utilities.  That doesn't mean we
 shouldn't implement wctype.h et al, but it does mean that we should
 use whichever facilities are cleanest, and easiest to code for and
 maintain, rather than those which are specifically blessed by an ISO
 working group.

In general wc*() functions provide more flexibility than runes, but in
case we discuss there is no difference.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: Request for review [Re: /bin/ls patch round #2]

[Michael C . Wu]

On Wed, Mar 21, 2001 at 03:29:52PM -0500, Don Croyle scribbled:
| "Andrey A. Chernov" [EMAIL PROTECTED] writes:
| 
|  I fully agree. wctype.h and isw*() must be implemented first instead of
|  hacking or using private interface (like runes) in userland program.
|  It will be easy to implement them over existen ctype mechanism masking
|  runes with wchar_t. Any takers?
| 
| If we're not going to bring in CITRUS, I'd prefer to see runes junked

We(I) will. 

| as an unnecessary layer of abstraction.  Doing so would break
| backwards compatibility for locales, but I think we're going to end up
| doing that eventually anyway.

-- 
+---+
| [EMAIL PROTECTED] | [EMAIL PROTECTED]   |
| http://iteration.net/~keichii | Yes, BSD is a conspiracy. |
+---+

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

Re: Request for review [Re: /bin/ls patch round #2]

[Jeroen Ruigrok/Asmodai]

-On [20010320 09:09], MINOURA Makoto ([EMAIL PROTECTED]) wrote:
Use standard types and functions such as wchar_t and mb*,
wc* family.

Which is still something which needs to be done yes.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
The Prince of Darkness is a gentleman...

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

Re: Request for review [Re: /bin/ls patch round #2]

[Garrett Wollman]

On 20 Mar 2001 15:53:21 +0900, [EMAIL PROTECTED] (MINOURA Makoto) said:

 In general direct manipulation of rune is evil.
 It is an internal data structure in libc;

Not true.  The `rune' API was developed by the Plan 9 people by
intention to be different from (in their view, superior to) the ISO C
multibyte/wide character API.

 Actually NetBSD does not export rune.h.

Note the mailing-lists named in the headers of this message.

-GAWollman


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

Re: Request for review [Re: /bin/ls patch round #2]

[MINOURA Makoto]

| In [EMAIL PROTECTED]
|  Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] wrote:

 Which is still something which needs to be done yes.

Hmmm, I didn't know that... FreeBSD lacks iswprint() etc...

It's..., it's ok, Michael is right, there's no way to do that
w/o adding some functions to libc.  Ideally we have to
implement isw*() family though, of course.

-- 
Minoura Makoto [EMAIL PROTECTED]

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

Re: Request for review [Re: /bin/ls patch round #2]

[MINOURA Makoto]

| In [EMAIL PROTECTED]
|  Garrett Wollman [EMAIL PROTECTED] wrote:

 Not true.  The `rune' API was developed by the Plan 9 people by
 intention to be different from (in their view, superior to) the ISO C
 multibyte/wide character API.

But not widely adopted.  ISO C is well-maintained so that
it's now superior to rune, I think.
Sorry I'm not sure but rune API is slightly different
between 4.4BSD and Plan9, isn't it?  It's not a standard.

Sources of the standard commands are often used as a living
textbook to other programmers.  They should be as `good' as
possible, and in my opinion `good' includes `standard-complient'.


 Note the mailing-lists named in the headers of this message.

I know that.  Just FYI.  Of course it's nonsence if you
think we should go our own alone way.

-- 
Minoura Makoto [EMAIL PROTECTED]

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

Request for review [Re: /bin/ls patch round #2]

[Michael C . Wu]

Hi Everyone,

This patch should allow our /bin/(color)ls to output Chinese,
Japanese, Korean, and all European languages(including Russian)
correctly.  Thinker and I both tested this independently.
isprint() already checks for _CTYPE stuff that Ache asked us to check.

Thinker also fixed the infinite loop in this patch.
This should all us to catch up with GNU/Linux and gnuls somewhat. :)

Please review this patch and comment on it.  I plan to commit
this in a few days if there are no more objections.

Thanks, 
Michael

On Mon, Mar 19, 2001 at 07:54:38PM -0600, Michael C . Wu scribbled:
| Hi everyone,
| Is this satisfactory with you all?  
| Ache: how should we check for Russian and single-byte char compatibility?
| - Forwarded message from thinker [EMAIL PROTECTED] -
| From: thinker [EMAIL PROTECTED]
| 
| Following is new patch file for /bin/ls.
| -
| --- util.c.orig   Sun Mar 18 16:35:12 2001
| +++ util.cTue Mar 20 09:49:47 2001
| @@ -52,6 +52,7 @@
|  #include stdio.h
|  #include stdlib.h
|  #include string.h
| +#include rune.h
|  
|  #include "ls.h"
|  #include "extern.h"
| @@ -60,15 +61,36 @@
|  prn_printable(s)
|   const char *s;
|  {
| - unsigned char c;
| - int n;
| + const char *p1, *p2;
| + char *r, *ri;
| + int len, dc;
| + rune_t c;
|  
| - for (n = 0; (c = *s) != '\0'; ++s, ++n)
| - if (isprint(c))
| - putchar(c);
| - else
| - putchar('?');
| - return n;
| + p1 = s;
| + dc = len = strlen(s);
| + ri = r = (char *)malloc(len + 1);
| + while(*p1 != 0) {
| + c = sgetrune(p1, dc, p2);
| + if(c == _INVALID_RUNE) {
| + p1++;
| + dc--;
| + *ri++ = '?';
| + } else {
| + dc -= p2 - p1;
| + if(isprint(c))
| + while(p1 != p2)
| + *ri++ = *p1++;
| + else
| + while(p1 != p2) {
| + *ri++ = '?';
| + p1++;
| + }
| + }
| + }
| + *ri = 0;
| + printf("%s", r);
| + free(r);
| + return len;
|  }
|  
|  /*


-- 
+---+
| [EMAIL PROTECTED] | [EMAIL PROTECTED]   |
| http://iteration.net/~keichii | Yes, BSD is a conspiracy. |
+---+

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

Re: Request for review [Re: /bin/ls patch round #2]

[Warner Losh]

In message [EMAIL PROTECTED] "Michael C . Wu" writes:
: | +   while(*p1 != 0) {
while (*p1 != '\0') {
: | +   c = sgetrune(p1, dc, p2);
: | +   if(c == _INVALID_RUNE) {

space after the if.  ditto further .

: | +   p1++;
: | +   dc--;
: | +   *ri++ = '?';
: | +   } else {
: | +   dc -= p2 - p1;
: | +   if(isprint(c))
: | +   while(p1 != p2)
: | +   *ri++ = *p1++;
: | +   else
: | +   while(p1 != p2) {
: | +   *ri++ = '?';
: | +   p1++;
: | +   }
I think this might be clearer:
if (isprint(c))
strlcpy(ri, p1, p2 - p1);
else
memset(ri, '?', p2 - p1);
ri += (p2 - p1);
p1 = p2;

: | +   return len;

Style(9) wants parens around (len).

Warner

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

Re: Request for review [Re: /bin/ls patch round #2]

[MINOURA Makoto]

| In [EMAIL PROTECTED]
|  "Michael C . Wu" [EMAIL PROTECTED] wrote:

 Please review this patch and comment on it.  I plan to commit
 this in a few days if there are no more objections.

OBJECTION.

In general direct manipulation of rune is evil.
It is an internal data structure in libc; using it from
ordinary applications breaks portability and is not
future-proof (in case we'd overhaul the locale
implementation).

Actually NetBSD does not export rune.h.

-- 
Minoura Makoto [EMAIL PROTECTED]

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

Re: Request for review [Re: /bin/ls patch round #2]

[Michael C . Wu]

On Tue, Mar 20, 2001 at 03:53:21PM +0900, MINOURA Makoto scribbled:
| 
| | In [EMAIL PROTECTED]
| |  "Michael C . Wu" [EMAIL PROTECTED] wrote:
| 
|  Please review this patch and comment on it.  I plan to commit
|  this in a few days if there are no more objections.
| 
| OBJECTION.

Please do not type in all capitals.  

| In general direct manipulation of rune is evil.
| It is an internal data structure in libc; using it from
| ordinary applications breaks portability and is not

portability to what?  We import colorls from outside,
and I do not know what you want to "port" to that this
would not work on.

| future-proof (in case we'd overhaul the locale
| implementation).
| 
| Actually NetBSD does not export rune.h.

So, will you please tell me how to solve this without
having me rewrite libc?

We could always have a ports//colorls...Oh wait,
we can just use gnuls.
-- 
+---+
| [EMAIL PROTECTED] | [EMAIL PROTECTED]   |
| http://iteration.net/~keichii | Yes, BSD is a conspiracy. |
+---+

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

Re: Request for review [Re: /bin/ls patch round #2]

[MINOURA Makoto]

| In [EMAIL PROTECTED]
|  "Michael C . Wu" [EMAIL PROTECTED] wrote:

 portability to what?  We import colorls from outside,
 and I do not know what you want to "port" to that this
 would not work on.

Ok. I'll paraphrae it.  It is not the right way.


 So, will you please tell me how to solve this without
 having me rewrite libc?

Use standard types and functions such as wchar_t and mb*,
wc* family.

-- 
Minoura Makoto [EMAIL PROTECTED]

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

Request For Review: libc/libc_r changes to allow -lc_r

[Daniel Eischen]

[ Followups to -arch only please ]

I've got some changes to libc and libc_r that I'd like reviewed.
These changes eliminate the _THREAD_SAFE macro and allow a libc
and libc_r that can be linked together via -lc_r.  This also means
that -pthread and -D_THREAD_SAFE can be deprecated.  Note that
libc_r could be now be renamed libpthread, but I would like to
reserve that for KSE Project development where we might want to
have both libraries around while libpthread (using KSEs) is being
developed.

The diffs are posted at:

  http://people.freebsd.org/~deischen/libc.diffs
  http://people.freebsd.org/~deischen/libc_r.diffs

The libc diffs include src/include, src/lib/libc, as well as
src/usr.sbin/pppctl (our only threaded app) changes, whereas
the libc_r diffs are just those changes to src/lib/libc_r.

I've tested these changes with ACE, but still have other testing
that I'll be doing over the weekend.  The patches have also
survived a buildworld, but the installworld will have to wait
for this weekend.  If you try these patches make sure you save a
copy of libc.so.5 just in case...

And BTW, many thanks to John Polstra for explaining some of the
issues involved with linking :-)


Overview of the changes
---

For those not familiar with our current libc_r, it is currently
built to include a thread-safe libc as well as the POSIX threads
routines.  On the other hand, libc is built to be non-thread
safe.  This differs from other OSs and from what POSIX mandates
and means that we require non-standard hacks like the linker
option -pthread (which links to libc_r and prevents linking to
libc).

System calls that need to be wrapped (HIDDEN_SYSCALLS) are now
defined in libc/Makefile instead of libc_r/Makefile.  This means
that libc now contains:

_thread_sys_foo - actual syscall
_foo- weak definition to _thread_sys_foo
foo - weak definition to _thread_sys_foo

I've changed all the instances of foo() to _foo() in libc for
those hidden system calls.  Anyone modifying or adding to libc
will have to be careful to use the same conventions.

In order to define the prototypes for _foo(), we introduce
namespace.h and un-namespace.h.  BDE suggested this as a way to
define the prototypes for the hidden system calls.  Use them as
follows:

#include "namespace.h"
#include unistd.h
/* Other standard includes... */
#include "un-namespace.h"

/*
 * DB contains the member 'close' which is defined to
 * _close if included before un-namespace.h
 */
#include db.h

/* Other local includes... */

int
somelibcfunc(int fd, void *buf, size_t len)
{
...
ret = (int)_read(fd, buf, len);
...
return (ret);
}

Including namespace.h will define those hidden system calls used
within libc from foo to _foo; un-namespace.h will undefine them.
A few others are defined as well, such as _pthread_mutex_lock and
friends.  This allows libc_r to provide replacement functions for
them if it is also linked in.

One note about lib/libc/stdio/mktemp.c.  This file really wants
to use namespace.h but can't because it is used in building part
of the C compiler (or something like that; the error has long
since scrolled off my window).

There are basically only two changes to libc_r.  One is to implement
the pthread_foo() functions as _pthread_foo() and make pthread_foo
a weak definition to _pthread_foo.  This allows an application to
have it's own pthread_foo().  I noticed Solaris does this to
libpthread as well as to libc.

The other change to libc_r is to eliminate references to the
global _thread_run and replace them with a function call to get
the currently running thread (which will be needed for the KSE
project).  Yes, I could do something like errno, but that wouldn't
encourage getting the running thread once and caching it.

Comments welcome,

-- 
Dan Eischen


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

Request for review: locale aliases support for libc

[Alexey Zelkin]

hi,

please review and comment

--

This is set of patches for libc which allow user to use locale
aliases. Currently it's only possible to use locale aliases
by creating one more symbolic link in /usr/share/locale, i.e.
if I want to have locale named "ru" I have to:

ln -s /usr/share/locale/ru_RU.KOI8-R /usr/share/locale/ru

With this set of patches we need no anymore to create any symbolic
links, but edit /usr/share/locale/locale.aliases file. Format of this
file is quite simple:

locale alias name real locale name

All lines which starting from '#' or empty lines are ignored.
Example locale.aliases file is included to this patchset.

-- 
/* Alexey Zelkin[EMAIL PROTECTED]   */
/* Tavric National University   [EMAIL PROTECTED]*/
/* Sysadmin/Developer   [EMAIL PROTECTED] */

 libc_locale_alias.tgz

Re: Request for review: locale aliases support for libc

[Andrey A. Chernov]

On Tue, Aug 29, 2000 at 02:01:02PM +0300, Alexey Zelkin wrote:
 please review and comment

By quick looking I found this:

1) strtok() should not be used in libraries, use strsep() instead.

2) There is security hole with LOCALE_ALIASES_PATH env. issetugid() check
required.

3) The same functionality should be added to NLS (catgets() etc.) to make
it really working.


-- 
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/


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

Re: Request for review: locale aliases support for libc

[Andrey A. Chernov]

On Tue, Aug 29, 2000 at 03:19:00PM +0400, Andrey A. Chernov wrote:
 By quick looking I found this:
 
 1) strtok() should not be used in libraries, use strsep() instead.
 
 2) There is security hole with LOCALE_ALIASES_PATH env. issetugid() check
 required.
 
 3) The same functionality should be added to NLS (catgets() etc.) to make
 it really working.

4) Not lstat() but stat() should be used for existence checking.

-- 
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/


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

Re: Request for review: locale aliases support for libc

[Alexey Zelkin]

hi,

I have updated patchset. libc/nls part is comming soon.
 
* Synchronize behaviours for LOCALE_ALIASES_PATH and LOCALE_PATH handling.
  If attempt to open customized locale.aliases (declared by env variable
  LOCALE_ALIASES_PATH) is failed -- don't try to use default system
  locale.aliases instead.

* Fix potential security hole noted by ache@ -- use issetugid().

* Use stat() instead of lstat() for locale files existence checking.

* Slight optimization

-- 
/* Alexey Zelkin[EMAIL PROTECTED]   */
/* Tavric National University   [EMAIL PROTECTED]*/
/* Sysadmin/Developer   [EMAIL PROTECTED] */

 locale_aliases_patchset2.tgz

Re: Request for review: locale aliases support for libc

[Andrey A. Chernov]

On Tue, Aug 29, 2000 at 05:26:51PM +0300, Alexey Zelkin wrote:
 I have updated patchset. libc/nls part is comming soon.

Why you always check LC_CTYPE existance only? It may not exist but other
locale parts, f.e. LC_TIME are still valid. It is not required to have
LC_CTYPE for locale.

You need to check LC_* existence corresponding to setlocale() request
made.

-- 
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/


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

Re: Request for review: locale aliases support for libc

[Alexey Zelkin]

hi,

On Tue, Aug 29, 2000 at 07:00:47PM +0400, Andrey A. Chernov wrote:

 Why you always check LC_CTYPE existance only? It may not exist but other
 locale parts, f.e. LC_TIME are still valid. It is not required to have
 LC_CTYPE for locale.

I just randomly selected one of files which is exists in locale directory
and my check have only target to understand -- is given locale name
valid locale or its alias.

 You need to check LC_* existence corresponding to setlocale() request
 made.

What to check if LC_ALL request is given ?

-- 
/* Alexey Zelkin[EMAIL PROTECTED]   */
/* Tavric National University   [EMAIL PROTECTED]*/
/* Sysadmin/Developer   [EMAIL PROTECTED] */


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

Re: Request for review: locale aliases support for libc

[Konstantin Chuguev]

Alexey Zelkin wrote:

  You need to check LC_* existence corresponding to setlocale() request
  made.

 What to check if LC_ALL request is given ?


LC_ALL overrides all other LC_* variables. If it is set, there is no need to
check anything else.
Then you should check all other LC_*, and then LANG.

--
  * *Konstantin Chuguev - Application Engineer
   *  *  Francis House, 112 Hills Road
 *   Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E   WWW:http://www.dante.net





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

Re: Request for review: locale aliases support for libc

[Konstantin Chuguev]

Alexey Zelkin wrote:

You need to check LC_* existence corresponding to setlocale() request
made.
  
   What to check if LC_ALL request is given ?

  LC_ALL overrides all other LC_* variables. If it is set, there is no need to
  check anything else.

  Then you should check all other LC_*, and then LANG.

 As I understand you're answering in concept, but we are talking about
 exact case right now (see may patches attached to previous letter)

 I am trying to realize "is requested locale physicaly present on this system"
 or it's just an alias. Currently I am just testing presence of
 /usr/share/locale/$requested_locale/LC_CTYPE and make decision depends
 on stat(2) return value.


Perhaps you should check presence of any of the following files in a locale
directory:
LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_TIME,
and proceed if any of them has been found...

--
  * *Konstantin Chuguev - Application Engineer
   *  *  Francis House, 112 Hills Road
 *   Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E   WWW:http://www.dante.net





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

Re: Request for review: locale aliases support for libc

[Andrey A. Chernov]

On Tue, Aug 29, 2000 at 06:24:49PM +0300, Alexey Zelkin wrote:
  You need to check LC_* existence corresponding to setlocale() request
  made.
 
 What to check if LC_ALL request is given ?

Just repeat the same procedure as regular algorithm gives for LC_ALL
processing.

-- 
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/


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

Re: Request for review: locale aliases support for libc

[Alexey Zelkin]

hi,

On Tue, Aug 29, 2000 at 05:19:56PM +0100, Konstantin Chuguev wrote:

 Perhaps you should check presence of any of the following files in a locale
 directory:
 LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_TIME,

LC_NUMERIC ? :)

 and proceed if any of them has been found...

Sure. I do it already as you can see from patches.

-- 
/* Alexey Zelkin[EMAIL PROTECTED]   */
/* Tavric National University   [EMAIL PROTECTED]*/
/* Sysadmin/Developer   [EMAIL PROTECTED] */


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

Re: Request for review: locale aliases support for libc

[Marcel Moolenaar]

Alexey Zelkin wrote:
 
 I am trying to realize "is requested locale physicaly present on this system"
 or it's just an alias.

Can you not revert the test: if the locale is present in the alias file,
then it obviously is an alias; otherwise it should be present on the
system?

Just a quick thought...

-- 
Marcel Moolenaar
  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
  tel:  (408) 447-4222


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

Re: Request for review: locale aliases support for libc

[Marcel Moolenaar]

Marcel Moolenaar wrote:
 
 Alexey Zelkin wrote:
 
  I am trying to realize "is requested locale physicaly present on this system"
  or it's just an alias.
 
 Can you not revert the test: if the locale is present in the alias file,
 then it obviously is an alias; otherwise it should be present on the
 system?
 
 Just a quick thought...

Ignore me. I haven't had enough coffee yet...

-- 
Marcel Moolenaar
  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
  tel:  (408) 447-4222


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

Re: Request for review/comments - new option for uname(1)

[Chris Costello]

On Wednesday, August 09, 2000, Mark Ovens wrote:
 The only thing I couldn't work out is why sysctl() adds 5 spaces after
 the date sub-string, so I've haven't stripped them out (hence the
 indented third line).

   sysctl() does not do that, that's what the data in the kernel
is.  Look at src/sys/compile/[yourkernel]/vers.c (or
/usr/obj/usr/src/sys/[yourkernel]/vers.c).

-- 
|Chris Costello [EMAIL PROTECTED]
|Computers are not intelligent.  They only think they are.
`-


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

Re: Request for review/comments - new option for uname(1)

[Will Andrews]

On Wed, Aug 09, 2000 at 12:59:29AM +0100, Mark Ovens wrote:
 Is there any reason why this is unacceptable and could not be committed?

Because it can be done with an awk/sed script?

-- 
Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED]
GCS/E/S @d- s+:+ a--- C++ UB$ P+ L- E--- W+ N-- !o ?K w---
O- M+ V- PS+ PE++ Y+ PGP t++ 5 X+ R+ tv+ b++ DI+++ D+ 
G++ e h! r- y?


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

Re: Request for review/comments - new option for uname(1)

[Mark Ovens]

On Wed, Aug 09, 2000 at 02:33:44PM -0400, Will Andrews wrote:
 On Wed, Aug 09, 2000 at 12:59:29AM +0100, Mark Ovens wrote:
  Is there any reason why this is unacceptable and could not be committed?
 
 Because it can be done with an awk/sed script?
 

I'll forget about it then. I only did it because I was fed up with
manually editing the output so it was tidier in e-mails and PRs. Like
I said, it's not important.

Thanks for the feedback.

 -- 
 Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED]
 GCS/E/S @d- s+:+ a--- C++ UB$ P+ L- E--- W+ N-- !o ?K w---
 O- M+ V- PS+ PE++ Y+ PGP t++ 5 X+ R+ tv+ b++ DI+++ D+ 
 G++ e h! r- y?

-- 
4.4 - The number of the Beastie

51.44°N  FreeBSD - The Power To Serve http://www.freebsd.org
2.057°W  My Webpage http://ukug.uk.freebsd.org/~mark
mailto:[EMAIL PROTECTED]http://www.radan.com



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

Request for review/comments - new option for uname(1)

[Mark Ovens]

The output of ``uname -a'' appears in hundreds of e-mails and PRs yet
the output format is not ideal for this (especially e-mail in
80-column mail readers) as it is a single line.

Attached is a patch for an enhancement I've made that adds a new
option ``-A'' (rather than change ``-a'') that splits it up into 3
lines thus making it better for including verbatim in e-mails and PRs:

  # uname -A
  FreeBSD parish 4.1-STABLE FreeBSD 4.1-STABLE #0:
  Tue Aug  8 00:51:02 BST 2000
  mark@parish:/usr/src/sys/compile/PARISH i386

The only thing I couldn't work out is why sysctl() adds 5 spaces after
the date sub-string, so I've haven't stripped them out (hence the
indented third line).

Is there any reason why this is unacceptable and could not be committed?

BTW, please Cc: me.

Thanks for your time.

-- 
4.4 - The number of the Beastie

51.44°N  FreeBSD - The Power To Serve http://www.freebsd.org
2.057°W  My Webpage http://ukug.uk.freebsd.org/~mark
mailto:[EMAIL PROTECTED]http://www.radan.com



--- uname.c.origTue Aug  8 21:32:36 2000
+++ uname.c Tue Aug  8 21:53:20 2000
@@ -61,16 +61,20 @@
 #defineRFLAG   0x04
 #defineSFLAG   0x08
 #defineVFLAG   0x10
+#defineAFLAG   0x20
u_int flags;
int ch, mib[2];
size_t len, tlen;
char *p, *prefix, buf[1024];
 
flags = 0;
-   while ((ch = getopt(argc, argv, "amnprsv")) != -1)
+   while ((ch = getopt(argc, argv, "Aamnprsv")) != -1)
switch(ch) {
+   case 'A':
case 'a':
flags |= (MFLAG | NFLAG | RFLAG | SFLAG | VFLAG);
+   if (ch == 'A')
+   flags |= AFLAG;
break;
case 'p':
case 'm':
@@ -137,9 +141,22 @@
len = sizeof(buf);
if (sysctl(mib, 2, buf, len, NULL, 0) == -1)
err(1, "sysctl");
-   for (p = buf, tlen = len; tlen--; ++p)
-   if (*p == '\n' || *p == '\t')
-   *p = ' ';
+
+   if (flags  AFLAG) {
+   for (p = buf, tlen = len; tlen--; ++p)
+   if (*p == ':') {
+   *++p = '\n';
+   break;
+   }
+
+   if (buf[strlen(buf) - 1] == '\n')
+   buf[strlen(buf) - 1] = '\0';
+   } else {
+   for (p = buf, tlen = len; tlen--; ++p)
+   if (*p == '\n' || *p == '\t')
+   *p = ' ';
+   }
+
(void)printf("%s%.*s", prefix, (int)len, buf);
prefix = " ";
}

Re: Request for review (LPDEST vs PRINTER)

[Christopher Masto]

On Wed, Aug 02, 2000 at 09:35:23PM -0400, Garance A Drosihn wrote:
 The other printing-system alternative is LPRng (which people
 can install from ports).  LPRng does add the 'lpstat' command,
 in addition to replacing lpr/lpq/lprm.  And if I am reading
 this code right, it does check LPDEST for all of those commands,
 *-but-* it has PRINTER taking precedence over LPDEST, and not
 the way POSIX (apparently) describes it.

From testing, it appears that you are reading the code correctly.  The
documentation for LPRng, however, indicates for the SysV commands that
LPDEST takes precedence.  It's probably just an oversight.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


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

Request for review

[Mark Ovens]

I originally sent this to -committers but was advised that the
maintainers and -hackers or -current was more appropriate.

I've posted some patches for PR 14682 which include some changes to
the source code for lpr(1), lprm(1) etc.

Could someone review them for me please, especially the C code.

Thanks. (please Cc: me as I'm not subscribed to -current)

-- 
  If I buy a copy of WinDelete, and it doesn't delete Windows,
  am I entitled to my money back?

51.44°N  FreeBSD - The Power To Serve http://www.freebsd.org
2.057°W  My Webpage http://ukug.uk.freebsd.org/~mark
mailto:[EMAIL PROTECTED]http://www.radan.com



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

Re: Request for review (LPDEST vs PRINTER)

[Garance A Drosihn]

At 10:39 PM +0100 8/2/00, Mark Ovens wrote:
I originally sent this to -committers but was advised that the
maintainers and -hackers or -current was more appropriate.

I've posted some patches for PR 14682 which include some changes
to the source code for lpr(1), lprm(1) etc.

Could someone review them for me please, especially the C code.

Your comments in the PR included:

 Whilst investigating this problem I found in /usr/bin/lp:
 # Posix 1003.2 compliant print spooler interface.
[snip]
 # Posix says LPDEST gets precedence over PRINTER
 dest=${LPDEST:-${PRINTER:-lp}}
 
 So it would seem that the Right Thing(tm) to do is to make
 the other programs POSIX-compliant by making them honour the
 LPDEST environment variable rather than simply documenting
 the fact that they don't (the manpages need updating to
 reflect this).

Strictly speaking, that is not the right thing to do. POSIX
is talking about the 'lp' command, which is one of the commands
from the SysV-ish printing world.  'lpr' is the BSD-ish print
world, and therefore it is not covered by what POSIX describes
for 'lp'.  These are two different command sets for printing.

The 'lprm' command is also part of the BSD-ish print world.
I do not have a reference for what POSIX says about commands,
but the "Single Unix Specification" has a description of the
'lp' command.  The description for 'lp' does not talk about
the 'lprm' command.  It says the way to cancel print jobs
sent via the 'lp' command is via the 'cancel' command.  It
also talks about using 'lpstat' instead of 'lpq'.

So, strictly speaking, if we wanted POSIX compliance then
we should add 'cancel' and 'lpstat' commands, and have
those commands behave as POSIX describes them.  If POSIX does
also describe the behavior of the 'lprm' or 'lpq' commands,
then we could talk about changing those commands to be
POSIX-compliant.  I would guess that it doesn't have them.

So, that is my off-the-cuff pedantic-mode reaction, which is
not much help in closing the PR...

I don't feel too strongly about this, but in general I'd
rather document that LPDEST is not used by lpr/lpq/lprm,
and maybe later on add cancel/lpstat commands for those
people who are really expecting the "POSIX print system".

The other printing-system alternative is LPRng (which people
can install from ports).  LPRng does add the 'lpstat' command,
in addition to replacing lpr/lpq/lprm.  And if I am reading
this code right, it does check LPDEST for all of those commands,
*-but-* it has PRINTER taking precedence over LPDEST, and not
the way POSIX (apparently) describes it.  If we do add checking
for LPDEST, I would probably have PRINTER continue to take
precedence over LPDEST.  Right now, anyone who *is* setting
both variables must be used to the idea that PRINTER is the
value lpr/lprm/lpq uses, and I do not think we should change
that.

I would also like to see what openbsd and netbsd do for this,
if anything, but I haven't the time right now.

As to your actual C code, it looks like it would work fine, if
we wanted to do that.


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


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

Re: request for review, patch to specfs to fix EOF condition alignmentwith buffer

[Julian Elischer]

On Wed, 22 Sep 1999, Bruce Evans wrote:

  This is a request for a review.  This patch fixes a bug in specfs
 
 It is a bit over-commented, and returns wrong error codes for EOF.

This is certainly not over commented in my opinion.
I wish more people would comment as much as Matt does.

 



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

request for review, patch to specfs to fix EOF condition alignment with buffer

[Internet MailSystem]

This is a request for a review.  This patch fixes a bug in specfs
relating to dealing with the EOF condition of a block device.

If the EOF occurs in the middle of a block, specfs was not
properly calculating the truncation for the I/O.

This problem was first found by Tor.  Tor's example creates
an oddly-sized VN partition and then  dd's from it.  Without the
patch the dd believes that it can read 2880 sectors.  With the
patch it correctly reads the last (truncated) block.

dd if=/dev/zero of=/tmp/floppy.img bs=512 count=2879
vnconfig -s labels -c /dev/vn0 /tmp/floppy.img
dd if=/dev/vn0 of=/dev/null bs=8k

Once this patch is committed, the only problem we will have is
in recognizing the write-EOF case, which I will have a 
recommendation for after this patch goes in.

A similar problem in the VN device has already been fixed and
committed.

-Matt

Index: miscfs/specfs/spec_vnops.c
===
RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v
retrieving revision 1.108
diff -u -r1.108 spec_vnops.c
--- spec_vnops.c1999/09/17 06:10:26 1.108
+++ spec_vnops.c1999/09/20 17:50:48
@@ -311,19 +311,37 @@
do {
bn = btodb(uio-uio_offset)  ~(bscale - 1);
on = uio-uio_offset % bsize;
-   n = min((unsigned)(bsize - on), uio-uio_resid);
if (seqcount  1) {
nextbn = bn + bscale;
error = breadn(vp, bn, (int)bsize, nextbn,
(int *)bsize, 1, NOCRED, bp);
} else {
error = bread(vp, bn, (int)bsize, NOCRED,
bp);
+   }
+
+   /*
+* Figure out how much of the buffer is valid
relative
+* to our offset into the buffer, which may be
negative
+* if we are beyond the EOF.
+*
+* The valid size of the buffer is based on 
+* bp-b_bcount (which may have been truncated by
+* dscheck or the device) minus bp-b_resid, which
+* may be indicative of an I/O error if non-zero.
+*/
+   n = bp-b_bcount - on;
+   if (n  0) {
+   error = EINVAL;
+   } else {
+   n -= bp-b_resid;
+   if (n  0)
+   error = EIO;
}
-   n = min(n, bsize - bp-b_resid);
if (error) {
brelse(bp);
return (error);
}
+   n = min(n, uio-uio_resid);
error = uiomove((char *)bp-b_data + on, n, uio);
brelse(bp);
} while (error == 0  uio-uio_resid  0  n != 0);
@@ -403,16 +421,48 @@
do {
bn = btodb(uio-uio_offset)  ~blkmask;
on = uio-uio_offset % bsize;
+
+   /*
+* Calculate potential request size, determine
+* if we can avoid a read-before-write.
+*/
n = min((unsigned)(bsize - on), uio-uio_resid);
if (n == bsize)
bp = getblk(vp, bn, bsize, 0, 0);
else
error = bread(vp, bn, bsize, NOCRED, bp);
+
+   /*
+* n is the amount of effective space in the buffer
+* that we wish to write relative to our offset into
+* the buffer. We have to truncate it to the valid
+* size of the buffer relative to our offset into
+* the buffer (which may end up being negative if
+* we are beyond the EOF).
+*
+* The valid size of the buffer is based on 
+* bp-b_bcount (which may have been truncated by
+* dscheck or the device) minus bp-b_resid, which
+* may be indicative of an I/O error if non-zero.
+*
+* XXX In a newly created buffer, b_bcount == bsize
+* and, being asynchronous, we have no idea of the
+* EOF.
+*/
+   if (error == 0) {
+   n = min(n, bp-b_bcount

request for review, patch to specfs to fix EOF condition alignment with buffer

[Matthew Dillon]

This is a request for a review.  This patch fixes a bug in specfs
relating to dealing with the EOF condition of a block device.

If the EOF occurs in the middle of a block, specfs was not
properly calculating the truncation for the I/O.

This problem was first found by Tor.  Tor's example creates
an oddly-sized VN partition and then  dd's from it.  Without the
patch the dd believes that it can read 2880 sectors.  With the
patch it correctly reads the last (truncated) block.

dd if=/dev/zero of=/tmp/floppy.img bs=512 count=2879
vnconfig -s labels -c /dev/vn0 /tmp/floppy.img
dd if=/dev/vn0 of=/dev/null bs=8k

Once this patch is committed, the only problem we will have is
in recognizing the write-EOF case, which I will have a 
recommendation for after this patch goes in.

A similar problem in the VN device has already been fixed and
committed.

-Matt

Index: miscfs/specfs/spec_vnops.c
===
RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v
retrieving revision 1.108
diff -u -r1.108 spec_vnops.c
--- spec_vnops.c1999/09/17 06:10:26 1.108
+++ spec_vnops.c1999/09/20 17:50:48
@@ -311,19 +311,37 @@
do {
bn = btodb(uio-uio_offset)  ~(bscale - 1);
on = uio-uio_offset % bsize;
-   n = min((unsigned)(bsize - on), uio-uio_resid);
if (seqcount  1) {
nextbn = bn + bscale;
error = breadn(vp, bn, (int)bsize, nextbn,
(int *)bsize, 1, NOCRED, bp);
} else {
error = bread(vp, bn, (int)bsize, NOCRED, bp);
+   }
+
+   /*
+* Figure out how much of the buffer is valid relative
+* to our offset into the buffer, which may be negative
+* if we are beyond the EOF.
+*
+* The valid size of the buffer is based on 
+* bp-b_bcount (which may have been truncated by
+* dscheck or the device) minus bp-b_resid, which
+* may be indicative of an I/O error if non-zero.
+*/
+   n = bp-b_bcount - on;
+   if (n  0) {
+   error = EINVAL;
+   } else {
+   n -= bp-b_resid;
+   if (n  0)
+   error = EIO;
}
-   n = min(n, bsize - bp-b_resid);
if (error) {
brelse(bp);
return (error);
}
+   n = min(n, uio-uio_resid);
error = uiomove((char *)bp-b_data + on, n, uio);
brelse(bp);
} while (error == 0  uio-uio_resid  0  n != 0);
@@ -403,16 +421,48 @@
do {
bn = btodb(uio-uio_offset)  ~blkmask;
on = uio-uio_offset % bsize;
+
+   /*
+* Calculate potential request size, determine
+* if we can avoid a read-before-write.
+*/
n = min((unsigned)(bsize - on), uio-uio_resid);
if (n == bsize)
bp = getblk(vp, bn, bsize, 0, 0);
else
error = bread(vp, bn, bsize, NOCRED, bp);
+
+   /*
+* n is the amount of effective space in the buffer
+* that we wish to write relative to our offset into
+* the buffer. We have to truncate it to the valid
+* size of the buffer relative to our offset into
+* the buffer (which may end up being negative if
+* we are beyond the EOF).
+*
+* The valid size of the buffer is based on 
+* bp-b_bcount (which may have been truncated by
+* dscheck or the device) minus bp-b_resid, which
+* may be indicative of an I/O error if non-zero.
+*
+* XXX In a newly created buffer, b_bcount == bsize
+* and, being asynchronous, we have no idea of the
+* EOF.
+*/
+   if (error == 0) {
+   n = min(n, bp-b_bcount

Re: request for review, patch to specfs to fix EOF condition alignment with buffer

[Poul-Henning Kamp]

Once this patch is committed, the only problem we will have is
in recognizing the write-EOF case, which I will have a 
recommendation for after this patch goes in.

...and the lack of error code returns on write.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Andreas Klemm]

On Mon, Sep 06, 1999 at 02:12:53PM -0700, David Greenman wrote:
 
I think they should all have .log since there can be subdirectories and it
 makes the files more easily identifiable.

You're right ... I understand ...

-- 
Andreas Klemm  http://www.FreeBSD.ORG/~andreas
 http://www.freebsd.org/~fsmp/SMP/SMP.html
   powered by Symmetric MultiProcessor FreeBSD
Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html


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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Nick Hibma]

Uhm, well, yes, but I just committed the patch for /var/cron/log to
/var/log/cron and not cron.log. So I guess that Andreas' idea has been
incorporated.

Nick


  On Mon, Sep 06, 1999 at 02:12:53PM -0700, David Greenman wrote:
   
  I think they should all have .log since there can be subdirectories and it
   makes the files more easily identifiable.
  
  You're right ... I understand ...
  
  

-- 
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy



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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Nick Hibma]

  Every time they ask you why we do things the way we do, and after you
  have taken the N minutes to explain it, ask them to go ask Sun the
  same question, out of fairness to FreeBSD.  It might put these ``Sun is
  the world'' guys back into thier place.  Or atleast it might get them
  off your back about these somewhat minor changes that are mostly made
  to make things clean and consistent.

"How do you mean strange location? Having to recompile sendmail to get
rid of forced-down-your-throat-NIS is the obvious thing to do isn't it?"


Nick




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

request for review: move of /var/cron/log to /var/log/cron.log

[Nick Hibma]

Please review the following patch to get all the log files in one place.
The commit will be accompanied by a HEADS UP. If no one objects I will
commit this in a couple of days.

Cheers,

Nick


Index: UPDATING
===
RCS file: /home/ncvs/src/UPDATING,v
retrieving revision 1.43
diff -u -w -r1.43 UPDATING
--- UPDATING1999/08/31 17:07:14 1.43
+++ UPDATING1999/09/05 09:27:27
@@ -3,6 +3,9 @@
 This file is maintained by [EMAIL PROTECTED]  Please send new entries
 directly to him.  See end of file for further details.
 
+19990905:
+   /var/cron/log has been moved to /var/log/cron.log to get all the
+   log files in one place.
 19990831:
tn3270 has been removed from the based system and added as a port.
 
Index: etc//Makefile
===
RCS file: /home/ncvs/src/etc/Makefile,v
retrieving revision 1.204
diff -u -w -r1.204 Makefile
--- Makefile1999/08/27 23:23:40 1.204
+++ Makefile1999/09/05 09:26:11
@@ -48,7 +48,7 @@
${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 755 ${BIN2} ${DESTDIR}/etc; \
${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 644 defaults/rc.conf 
${DESTDIR}/etc/defaults/; \
${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 600 /dev/null \
-   ${DESTDIR}/var/cron/log; \
+   ${DESTDIR}/var/log/cron.log; \
${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 600 \
master.passwd ${DESTDIR}/etc; \
( cd ${.CURDIR}/periodic; ${MAKE} install );\
Index: etc//newsyslog.conf
===
RCS file: /home/ncvs/src/etc/newsyslog.conf,v
retrieving revision 1.23
diff -u -w -r1.23 newsyslog.conf
--- newsyslog.conf  1999/08/27 23:23:42 1.23
+++ newsyslog.conf  1999/09/05 09:26:25
@@ -2,7 +2,7 @@
 # $FreeBSD: src/etc/newsyslog.conf,v 1.23 1999/08/27 23:23:42 peter Exp $
 #
 # logfilename  [owner:group]mode count size when [ZB] [/pid_file] 
[sig_num]
-/var/cron/log  600  3 100  * Z
+/var/log/cron.log  600  3 100  * Z
 /var/log/amd.log   664  7 100  * Z
 /var/log/kerberos.log  664  7 100  * Z
 /var/log/lpd-errs  664  7 100  * Z
Index: etc//syslog.conf
===
RCS file: /home/ncvs/src/etc/syslog.conf,v
retrieving revision 1.11
diff -u -w -r1.11 syslog.conf
--- syslog.conf 1999/08/27 23:23:45 1.11
+++ syslog.conf 1999/09/05 09:26:39
@@ -7,7 +7,7 @@
 security.* /var/log/security
 mail.info  /var/log/maillog
 lpr.info   /var/log/lpd-errs
-cron.* /var/cron/log
+cron.* /var/log/cron.log
 *.err  root
 *.notice;news.err  root
 *.alertroot



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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Doug]

Nick Hibma wrote:
 
 Please review the following patch to get all the log files in one place.
 The commit will be accompanied by a HEADS UP. If no one objects I will
 commit this in a couple of days.

The only thing I don't like about this is that it introduces a point of
incompatibility between FreeBSD and other unices, and I'm not sure the
benefit is worth it. I would bring up the idea of creating a symlink in
/var/log, but I know that the purists would never approve of that...

Doug


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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Matthew Dillon]

:Nick Hibma wrote:
: 
: Please review the following patch to get all the log files in one place.
: The commit will be accompanied by a HEADS UP. If no one objects I will
: commit this in a couple of days.
:
:   The only thing I don't like about this is that it introduces a point of
:incompatibility between FreeBSD and other unices, and I'm not sure the
:benefit is worth it. I would bring up the idea of creating a symlink in
:/var/log, but I know that the purists would never approve of that...
:
:Doug

cron putting its log file in /var/cron has always bothered me in the past,
because we have this wonderful /var/log directory.  Not enough for me
to change it, though.  Still, I think it's a good idea to make this change
in current.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Nick Hibma]

  Please review the following patch to get all the log files in one place.
  The commit will be accompanied by a HEADS UP. If no one objects I will
  commit this in a couple of days.
 
   The only thing I don't like about this is that it introduces a point of
 incompatibility between FreeBSD and other unices, and I'm not sure the
 benefit is worth it. I would bring up the idea of creating a symlink in
 /var/log, but I know that the purists would never approve of that...

What about the other way around?

Nick

-- 
e-Mail: [EMAIL PROTECTED]



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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Mike Muir]

Doug wrote:
 
 Nick Hibma wrote:
 
  Please review the following patch to get all the log files in one place.
  The commit will be accompanied by a HEADS UP. If no one objects I will
  commit this in a couple of days.
 
 The only thing I don't like about this is that it introduces a point of
 incompatibility between FreeBSD and other unices, and I'm not sure the
 benefit is worth it. I would bring up the idea of creating a symlink in
 /var/log, but I know that the purists would never approve of that...

Whats wrong with FreeBSD going to the fore as far as common sense goes?
Are there standards that specify the location of cron's logs? So why
not.. maybe other unices will do the same when they see FreeBSD doing it
:D

mike.


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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Jordan K. Hubbard]

   The only thing I don't like about this is that it introduces a point of
 incompatibility between FreeBSD and other unices, and I'm not sure the

I think there was a lot of this sort of "compatibility" lost when BSD
introduced its whole hier(7) enforced subtree scheme, and about the
only OSes we're compatible with on log locations are other BSDs.

And I think there's a good chance of getting them to sync with this
commit since it does just Make Sense(tm).

- Jordan


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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Rodney W. Grimes]

 Nick Hibma wrote:
  
Please review the following patch to get all the log files in one place.
The commit will be accompanied by a HEADS UP. If no one objects I will
commit this in a couple of days.
  
 The only thing I don't like about this is that it introduces a point of
   incompatibility between FreeBSD and other unices, and I'm not sure the
   benefit is worth it. I would bring up the idea of creating a symlink in
   /var/log, but I know that the purists would never approve of that...
  
  What about the other way around?
 
   I could definitely live with that. I'm really not _against_ the change,
 and I do see the point of making things consistent. But I'm coming from the
 standpoint of someone who's trying to introduce freebsd into a previously
 all-sun shop, and every single little thing that's different gets me a
 funny look and N minutes of explanation as to why we do things the way we
 do. Personally I've taken to symlink'ing /var/adm/messages on the sun
 boxes, so having a symlink the other way around in this case is fine with
 me. 

Every time they ask you why we do things the way we do, and after you
have taken the N minutes to explain it, ask them to go ask Sun the
same question, out of fairness to FreeBSD.  It might put these ``Sun is
the world'' guys back into thier place.  Or atleast it might get them
off your back about these somewhat minor changes that are mostly made
to make things clean and consistent.

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


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

Re: request for review: move of /var/cron/log to /var/log/cron.log

[Doug]

Mike Smith wrote:
 
Don't get me wrong, my boss/cow orkers/etc. aren't morons, I would just
  like to avoid gratuitous differences for their own sake.
 
 "FreeBSD is not Solaris".  The differences aren't "gratuitous" because
 we're not trying to be "like Solaris" in the first place.  The
 differences that exist do so because our idea of "sensible" doesn't
 agree with Sun's.  The real discriminating factor there is that we do
 things that seem sensible to our community, while Sun do it however
 they please and then force their community to put up with it.

Sorry if I wasn't clear. I agree with you. I'm attempting to elucidate the
perspective of my coworkers. 

Doug


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

2nd request for review for vlan changes

[Bill Paul]

This is a second request for review for my proposed if_vlan updates.
Since I tweaked a couple of different things, I placed a tarball with
the sources at http://www.freebsd.org/~wpaul/VLAN/vlan.tar.gz (or,
for those of you with freebsd.org accounts,
~wpaul/public_html/VLAN/vlan.tag.gz). This contains updated sources
if_vlan.c, if_vlan_var.h and ifconfig.

The changes are as follows:

- If the IFF_LINK0 flag is set on a vlan pseudo-interface, it does not
  peform any header mangling to create the 802.1Q encapsulation, instead
  allowing the underlying parent driver to do it. (Again, this is mainly
  for the Tigon driver that I'm working on, which can do its own vlan
  tag insertion and extraction in firmware.) (I know I used LINK1 before;
  that's because I forgot that the flag values were zero-based and that
  LINK0 was really the first one. :)

  Note: vlan_start() will set rcvif on the outbound mbuf so that the
  parent driver can find the vlan interface where it originated and
  find the vlan tag. In order to avoid having the driver possibly
  follow an uninitialized rcvif pointer, vlan_start() will also set
  the M_PROTO1 flag in the mbuf to signal to the parent driver that
  the rcvif is valid.

- Implemented vlan_input_tag(), for use with interfaces that know how
  to do vlan tag extraction and de-capsulation on their own. Works like
  vlan_input(), except it accepts a third argument, t, which is the
  extracted vlan tag; given the tag, it tracks down the appropriate vlan
  interface and sends it the frame.

- Added support for multicast. The vlan pseudo interface adds entries
  to the parent's multicast filter using if_addmulti() and keeps a
  private list of those groups which it has added. If an update is done,
  the private list is removed with if_delmulti(), and the parent is
  programmed again (which again updates the private list). This is a
  little messy in principle, but the code is fairly simple.

- Implemented vlan_unconfig(), the opposite of vlan_config(). When
  setting up a vlan/parent association with SIOCSETVLAN, the parent's
  ethernet address and other info are copied to the vlan pseudo interface.
  This should be removed when the association is broken.

- Changed vlan_input()/vlan_input_tag() and vlan_start() to update
  ifp-if_ipackets and ifp-if_opackets respecively.

- If the output queue of the parent interface is full in vlan_start(),
  increment ifp-if_oerrors, free the mbuf, and continue, instead of
  just falling through and trying to queue the mbuf even though we know
  the output queue is full.

- Modified ifconfig(8) to allow setting the vlan tag and parent interface
  of a vlan interface, and to display the interface settings. Three new
  commands have been added: vlan, vlandev and -vlandev. To set up a vlan
  interface, you can do this:

# ifconfig vlan0 vlan 12345 vlandev foo0

  To break the association, you can do this:

# ifconfig vlan0 -vlandev foo0

  You have to set vlan and vlandev at the same time, since that's how the
  SIOCSETVLAN ioctl works. Also updated the ifconfig.8 man page.

- Fixed a bug in ifconfig. The setifflags() function does a SIOCGIFFLAGS
  on the ifreq structure that gets passed to it, however this clobbers
  part of it (namely sa_family) because everything after ifr_name is
  just one big union. This causes later portions of ifconfig that check
  the sa_family value to get confused. In my case, the effect was that
  when I did 'ifconfig vlan0 link0,' ifconfig printed out a line of
  appletalk status information because sa_family had gotten mangled to
  16 (AF_APPLETALK).

I still need to write a vlan(4) man page.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home:  wp...@skynet.ctr.columbia.edu | Columbia University, New York City
=
 It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness
=


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: 2nd request for review for vlan changes

[Amancio Hasty]

What is vlan?

Tnks,
Amancio




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: Request for review: changes to if_vlan.c

[John Polstra]

In article 18961.920316...@critter.freebsd.dk,
Poul-Henning Kamp  p...@critter.freebsd.dk wrote:
 
 It should have been done with a simple ascii string instead.  The
 drivers are much better at chewing on it than the generic code,
 it would be simpler to understand, simpler to implement, you wouldn't
 need to rebuild ifconfig all the time and it would be vastly more
 flexible.
 
 Anyone who thinks this sounds like a replay from when I stuck my
 fingers in sysctl some years back are right.
 
 GRUMBLE
 For some reason, some people around our camp-fire, have a hard time 
 understanding that compiletime enumeration of potential options
 is a concept that died with the VAX Handbook 1978 edition.
 /GRUMBLE

Amen, brother!  Get it said!  People who claim that strings are
too slow would benefit greatly from spending a few days with the
profiler.

John
-- 
  John Polstra   j...@polstra.com
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Nobody ever went broke underestimating the taste of the American public.
-- H. L. Mencken


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: Request for review: changes to if_vlan.c

[Matthew Jacob]

 
 Amen, brother!  Get it said!  People who claim that strings are
 too slow would benefit greatly from spending a few days with the
 profiler.

Now I'll stir the other pot and say that performance isn't the issue- the
issue is that there's nothing that says that strings and identifiers are
always easier to use and/or understand than numbers.




To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: Request for review: changes to if_vlan.c

[Poul-Henning Kamp]

In message pine.lnx.4.04.9903031215150.25376-100...@feral-gw, Matthew Jacob w
rites:
 
 Amen, brother!  Get it said!  People who claim that strings are
 too slow would benefit greatly from spending a few days with the
 profiler.

Now I'll stir the other pot and say that performance isn't the issue- the
issue is that there's nothing that says that strings and identifiers are
always easier to use and/or understand than numbers.

This is entirely besides the point.  We're talking about the cases where
people are going trough several layers of topological excercise to pack
strings into integer and bit fields rather than to pass them directly.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: Request for review: changes to if_vlan.c

[John Polstra]

Matthew Jacob wrote:

 Now I'll stir the other pot and say that performance isn't the
 issue- the issue is that there's nothing that says that strings and
 identifiers are always easier to use and/or understand than numbers.

They are a lot more extensible, though.  With strings, you generally
have to modify and recompile only the portion of the code that
implements new functionality.  The client code doesn't have to be
modified or even relinked.

John
---
  John Polstra   j...@polstra.com
  John D. Polstra  Co., Inc.Seattle, Washington USA
  Nobody ever went broke underestimating the taste of the American public.
-- H. L. Mencken


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message

Re: Request for review: changes to if_vlan.c

[Mikhail Teterin]

  Now I'll stir the other pot and say that performance isn't the
  issue- the issue is that there's nothing that says that strings and
  identifiers are always easier to use and/or understand than numbers.
 
 They are a lot more extensible, though. With strings, you generally
 have to modify and recompile only the portion of the code that
 implements new functionality. The client code doesn't have to be
 modified or even relinked.

May the strerror(3) be a good example of how to deal with numbers
AND strings?

-mi


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message