Linux-Development-Sys Digest #769, Volume #8 Sun, 3 Jun 01 15:13:14 EDT
Contents:
mmap not working properly?! (Chaos)
mmap not working(2) - kernel bug?! (Zeljko Vrba)
Re: mmap not working(2) - kernel bug?! (Zeljko Vrba)
Re: mmap not working(2) - kernel bug?! (Alexander Viro)
Re: mmap not working(2) - kernel bug?! (Zeljko Vrba)
Re: hash function for ip address (Joern Engel)
Re: fast disk writes (Nix)
Re: GNU_SOURCE (Nix)
symtab_begin.h and symtab_end.h: what do I use in 2.2? - use EXPORT_SYMBOL (Han Kim)
Problems With Dynamic Linking ("K")
Re: environment variable confusion (Eric Taylor)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Chaos)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development,hr.comp.os.linux
Subject: mmap not working properly?!
Date: 3 Jun 2001 07:02:14 GMT
Reply-To: [EMAIL PROTECTED]
The platform is:
Linux zax.private.hr 2.2.17 #2 Sun Sep 24 14:08:23 CEST 2000 i586 unknown
libc version: libc-2.1.3.so
Symptom:
Program received signal SIGBUS, Bus error.
0x804c9b6 in incr_acc (e=0x805c1a8, acc=0x40d62000, x=452, y=31, r=38.9310989,
alpha=-0.769707978) at ghtmatch.cc:300
Relevant code:
size_t idx = xc + yc*y_idxfac + pc*p_idxfac + sc*s_idxfac;
unsigned short q = acc[idx];
(gdb) print idx
$6 = 14158559
(gdb) print acc
$5 = (short unsigned int *) 0x40d62000
Code that caused the fault:
Dump of assembler code from 0x804c9b6 to 0x804c9c6:
0x804c9b6 <incr_acc__FP6RasterPUsiiff+322>: movzwl (%eax,%edx,1),%edx
0x804c9ba <incr_acc__FP6RasterPUsiiff+326>: mov %dx,0xffffffce(%ebp)
0x804c9be <incr_acc__FP6RasterPUsiiff+330>: mov 0xffffffd0(%ebp),%eax
0x804c9c1 <incr_acc__FP6RasterPUsiiff+333>: lea (%eax,%eax,1),%edx
0x804c9c4 <incr_acc__FP6RasterPUsiiff+336>: mov 0xc(%ebp),%eax
Register contents:
eax 0x40d62000 1087774720
ecx 0xd80adf 14158559
edx 0x1b015be 28317118
/proc/maps for the relevant file/memory range:
40d62000-44362000 rw-s 00000000 03:05 648185
/usr/home/zeljko/fax/segment/v4cmd/ACCU.ght
Now, if you calculate %eax+%edx, you will see that it is contained within
the mapped region. So why the process gets SIGBUS? (ACCU.ght is a mmaped()
sparse file large about 60MB).
But from the debugger it works:
(gdb) print acc[idx]
$4 = 0
Moreover, first few accesses to the mapped range succeed, and then it fails.
What could be the problem? Is the problem in 16-bit access, using a sparse
file, or what?
------------------------------
From: [EMAIL PROTECTED] (Zeljko Vrba)
Crossposted-To:
hr.comp.os.linux,comp.os.linux.development.apps,comp.os.linux.development,hr.comp.programiranje.c
Subject: mmap not working(2) - kernel bug?!
Date: 3 Jun 2001 07:56:39 GMT
Reply-To: [EMAIL PROTECTED]
[ Ispricavam se zbog engleske poruke na hr grupe, ali ne da mi se pisati dva
clanka / I apologize for English message in Croatian newsgroups, but I'm lazy
to write 2 articles. ]
So I have resolved my problem (if you have read my previous post about mmap).
It seems that Linux kernel is unable to handle sparse mmaped files. I allocate
the file like this (sz is something like 60MB, the size I need).
if((fd = open(fname, O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR)) < 0) {
perror("open");
exit(1);
}
if(lseek(fd, sz-1, SEEK_SET) < 0) {
perror("lseek");
exit(1);
}
write(fd, &c, 1);
The program works just fine (no SIGBUS anymore) without any modification
when I make a non-sparse with dd if=/dev/zero of=ACCU.ght bs=1024 size=65536 .
(except opening the file; I removed O_TRUNC from open() flags and lseek/write)
Now, I'd like to know what POSIX says about this? Does it even mention sparse
files or are they just Linux's method of saving disk space? Is this a known
bug? (I can't wait to test it on Monday on 2.4 kernel... :)
Have I stumbled upon a kernel bug and how do I report it?
------------------------------
From: [EMAIL PROTECTED] (Zeljko Vrba)
Crossposted-To:
hr.comp.os.linux,comp.os.linux.development.apps,comp.os.linux.development,hr.comp.programiranje.c
Subject: Re: mmap not working(2) - kernel bug?!
Date: 3 Jun 2001 08:38:43 GMT
Reply-To: [EMAIL PROTECTED]
Here's a small program that will reproduce a bug. It prints the index it
accesses BEFORE the actual access:
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main()
{
int fd;
char c = 0;
unsigned short *ptr;
size_t sz = 1 << 25; /* 32 million short's */
size_t step = (1 << 23) - (1 << 16) + 1; /* simulate random access pattern */
size_t i;
if((fd = open("TEST", O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR)) < 0) {
perror("open");
exit(1);
}
if(lseek(fd, sz-1, SEEK_SET) < 0) {
perror("lseek");
exit(1);
}
write(fd, &c, 1);
ptr = mmap(0, sz*sizeof(unsigned short),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if(ptr == MAP_FAILED) {
perror("mmap");
exit(1);
}
for(i = 0; i != 1; i = (i+step)%sz) {
printf("%d\n", i);
++ptr[i];
}
}
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To:
hr.comp.os.linux,comp.os.linux.development.apps,comp.os.linux.development,hr.comp.programiranje.c
Subject: Re: mmap not working(2) - kernel bug?!
Date: 3 Jun 2001 05:08:21 -0400
In article <[EMAIL PROTECTED]>,
Zeljko Vrba <[EMAIL PROTECTED]> wrote:
>Here's a small program that will reproduce a bug. It prints the index it
s/will reproduce/contains/
> if((fd = open("TEST", O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR)) < 0) {
OK, size of file is 0.
> perror("open");
> exit(1);
> }
> if(lseek(fd, sz-1, SEEK_SET) < 0) {
> perror("lseek");
> exit(1);
> }
> write(fd, &c, 1);
And now it's sz.
> ptr = mmap(0, sz*sizeof(unsigned short),
> PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> if(ptr == MAP_FAILED) {
> perror("mmap");
> exit(1);
> }
OK, so now you've mapped 2*sz. I.e. access to the second half of area
will SIGBUS. You have
sz = 1 << 25
step = (1 << 23) - (1 << 16) + 1
so
> for(i = 0; i != 1; i = (i+step)%sz) {
> printf("%d\n", i);
> ++ptr[i];
> }
will touch
* two bytes at offset 0
* two bytes at offset (1<<24) - (1<<17) + 2
* two bytes at offset (1<<25) - (1<<18) + 4
* two bytes at offset (1<<25) + (1<<24) - (1<<18) - (1<<17) + 6
At that point you are past the end of file. SIGBUS.
Touching stuff in holes is OK. Touching stuff past the end of file is
not.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Zeljko Vrba)
Crossposted-To:
hr.comp.os.linux,comp.os.linux.development.apps,comp.os.linux.development,hr.comp.programiranje.c
Subject: Re: mmap not working(2) - kernel bug?!
Date: 3 Jun 2001 10:48:15 GMT
Reply-To: [EMAIL PROTECTED]
On 3 Jun 2001 05:08:21 -0400, Alexander Viro <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Zeljko Vrba <[EMAIL PROTECTED]> wrote:
> >Here's a small program that will reproduce a bug. It prints the index it
>
> s/will reproduce/contains/
>
:))
>
> Touching stuff in holes is OK. Touching stuff past the end of file is
> not.
>
Wow. I guess I should have lseek'd to 2*sz-1. Tried it and it works now. thanx.
------------------------------
From: [EMAIL PROTECTED] (Joern Engel)
Subject: Re: hash function for ip address
Date: 3 Jun 2001 11:05:00 GMT
Reply-To: [EMAIL PROTECTED]
Hi!
>> ACP ~ Art of Computer Programming. It is a set of BOOKS...
Thank you! Might be good reading on a rainy day.
> For a quick and effective hash function, I would suggest a simple XOR of
> bits. IP addresses are sufficiently dense these days (if you are looking
> at the general internet domain) that the hash function would be
> reasonably uniform.
Actually, I am not the OP and looking for another kind of hash
function. It should identify files and be relatively fast and as
collision-free as possible.
My idea was to XOR the whole file in 128bit-chunks and add the first
and the last couple of bits. Collision-free with filesize <= hashsize
and collisions should still be rare with large files. Cryptographic
strength is not needed, so the increased namespace should give less
collisions than md5, shouldn't it?
Joern
------------------------------
From: Nix <$}xinix{$@esperi.demon.co.uk>
Subject: Re: fast disk writes
Date: 03 Jun 2001 15:45:02 +0100
On 03 Jun 2001, Kai Henningsen stipulated:
> [1] Getting Win32 to create a link is ... interesting. But possible (see,
s/interesting/insane/
(I mean, the backup API? What *were* they *thinking*?)
--
`Technology is meaningless. What matters is how people _think_
of it.' --- Linus Torvalds
------------------------------
From: Nix <$}xinix{$@esperi.demon.co.uk>
Subject: Re: GNU_SOURCE
Date: 03 Jun 2001 15:48:58 +0100
On 30 May 2001, Martin von Loewis stipulated:
> I was confused. I remembered it would define "many" functions, but
> mistook this that it would define everything it has.
It's probably because libc5 *did* define lots of GNU-specific stuff
(roughly what is now defined by -D_GNU_SOURCE); -D_GNU_SOURCE was
introduced to let people keep using it, while aiding portability by not
defining them for programs that don't expect/need it.
--
`Technology is meaningless. What matters is how people _think_
of it.' --- Linus Torvalds
------------------------------
From: [EMAIL PROTECTED] (Han Kim)
Subject: symtab_begin.h and symtab_end.h: what do I use in 2.2? - use EXPORT_SYMBOL
Date: 3 Jun 2001 10:01:16 -0700
I am replying to an old message dated
>Message 1 in thread
>From: Timur Tabi ([EMAIL PROTECTED])
>Subject: symtab_begin.h and symtab_end.h: what do I use in 2.2?
>Newsgroups: comp.os.linux.development.system
>Date: 2000/03/24
>It appears that the header files symtab_begin.h and symtab_end.h are no
>longer used in the 2.2 kernel. What do I use in 2.2? I can't find a
>kernel programming resource (on the web or in the bookstore) that talks
>about 2.0->2.2 differences.
I was also trying to figure out the equivalent of the symtab_begin.h
and symtab_end.h files while working on the examples in the Rubini book
"Linux Device Drivers".
I have Red Hat linux 7 which uses kernel version 2.2.16
I have seen several people looking for the same info but no reply on
the comp.*linux* newsgroups.
The macros:
EXPORT_NO_SYMBOLS;
EXPORT_SYMTAB;
EXPORT_SYMBOL(symbol_name);
EXPORT_SYMBOL_NOVERS(symbol_name);
take the place of the symtab_begin.h and symtab_end.h headers in 2.2 and
newer releases. Rubini talks about this in Chapter 17 of his Book. I missed
the pointer to Chapter 17 while I was trying to get the examples in
Chapter 2 to work.
I am posting this one for people like myself!
Han
------------------------------
From: "K" <[EMAIL PROTECTED]>
Subject: Problems With Dynamic Linking
Date: Sun, 3 Jun 2001 14:45:30 -0400
Can anyone inform me as to how to produce dynamically linked executables for
ARM linux? I used what I considered to be the normal method for producing
such executables, i.e.
arm-linux-gcc filename -o executable -Xlinker -Bdynamic -L. -ldl -llib
and it produces no dynamic segment in the ELF binary. I have also tried
with and without the -ldl tag. I think it could be that when I cross
compiled gcc for ARM, it may be hard coded to produce static binaries. I
would appreciate tutelage in the matter, or simply any dynamically linked
executable for ARM linux.
Kevin
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: environment variable confusion
Date: Sun, 03 Jun 2001 19:03:16 GMT
I want to thank you very much for the test program.
I now see 2 solutions to my problems:
=============
The right way:
1. save/restore the entire stack, include a reference
to environ in the base code and save this as a special
item to fixup after the restore.
===========
The lazy way (my management will probably go with this)
2. Before starting the program the first time, define some
number (say 10) of large environment variables. xxx1..xxx10
Don't save/restore environ and leave the stack as it is. Later,
if needed, delete one or more of these. Exec compacts memory
so this should move all things up enough so the restore no
longer gets into trouble overwriting anything critical.
=============
By keeping environ _out_ of the base code, then getenv will
be forced to use it's own value which exec will have to
load (I think exec must have some clever way to
find this value in the forked process before it wipes
out everything and does the load of the new program
probably as you said, it is in the elf tables).
I will try for 1. but use 2. if permitted.
BTW I also discovered that using the "screen" program to safeguard an
accidental closing of the window where the program runs (or
logging out of gnome) also results in an environment at lower
addresses. So, to use that program, I will have to make sure
it too is run at initial startup, and not only later when a restore is
tried.
Again, thanks very much for all the help and especially the
detailed test program along with the commands to build
and setup a dynamically loadable library. I will file that
away for any future use as a beautiful small example.
The example, repeated below, is a great guide to
anyone who wants to load a dynamic library - especially
useful as a way to add plugin support libraries.
regards and thanks to all (esp to B.D.)
eric
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Eric Taylor <[EMAIL PROTECTED]> wrote:
> >Wow, thanks for all the details, I think I see
> >what is going on now , and I have only
> >one more question (but first some explanation):
> >
> >----------------------------
> >When I grow the environment, the saved stack area gets
> >restored in the same place it was, but that now
> >overlaps the pointers to the env variables since
> >adding the large env variable results in everything
> >starting at a lower address. So, the env vector
> >gets clobbered on my (only partial) stack restore.
> >
> >I think you are correct that the entire top of
> >the stack should be saved/restored. But if I do
> >that, I think I would have to see that environ
> >got restored as well and I don't know how to
> >do that for the libc .so library.
> >
> >It was mentioned that if environ is in the bss
> >area, then even the .so libraries would use that.
> >otherwise they would use their own copy. I found
> >some source code that seems to indicate that
> >this might not happen
>
> I have tried a simple program that dynamically loads a library, which
> in turn, prints the address of environ and some selected entry. This
> works correctly whether or not the original program mentions environ.
> This library output indicates that both environ and __environ are in
> the program bss-area if it contains a reference to environ. I have
> included the two programs below.
>
> I believe that you could simply add a dummy reference to environ
> somewhere in your program and get it restored automatically with the
> rest of your data.
>
> >I found this definition in environ.c, but don't undestand
> >the comment:
> >--------
> >/* This must be initialized; we cannot have a weak alias into bss. */
> >char **__environ = NULL;
> >weak_alias (__environ, environ)
> >-----------
> >
> >
> >I stepped getenv thru with gdb. I found
> >the address of environ, in one of the rw sections of
> >libc .so dyn library. So, as mentioned, this must
> >be a dynamic environ and not in my bss area.
> >
> >I think my difficulty is that I don't understand how
> >weak or weak_alias is implemented.
>
> I don't know the details, and the documentation doesn't say anything
> about it, but the idea is essentially as follows. A library variable
> or function is provided with the "weak" attribute. If the user code
> doesn't provide one with the same name, the library version is linked.
> If the user does provide one, the library version is ignored.
>
> >So, the (final?) question is how does the loader know what value
> >to initialize this dynamic environ to? The correct value seems to be an
> >attribute of the new process that exec has just setup. But
> >it's not until a bit later that libc is loaded and that is when
> >environ comes into existance for libc.So the true value for
> >environ must be saved somewhere (in the kernel?) while
> >exec is setting up the environment. Or do I have the order
> >of this backwards?
>
> My guess is that ld-linux.so.2 does this. The exec() loading sequence
> first loads the user program, and then the "elf-interpreter." Control
> actually passes to the interpreter, which finally finds its way to the
> user program entry point via one of the elf-parameters on the stack.
> The interpreter loads and links libc et. al., and I would guess sees
> that the user program has an "environ" variable and links that into
> the various places that need it, including the references within libc.
> If you look for "V" entries in an nm listing of libc, you will find
> about fifteen other symbols like this. The idea here is that libraries
> can link to external symbols in other libraries, or even the user
> program. The weak definition is simply a fall-back when no external
> match is found.
>
> >Thanks again, as usual the help in this message board
> >is fabulous!!
> >
> >
> >
> >
> >--------------------------------------------------
> >Here is what I have been looking at. If there are any
> >assembler experts out there, maybe someone can
> >explain how this reference to __environ works.
> >
> >
> >
> >
> >Here is the beginning of getenv.c
> >---------------------------
> >#ifndef HAVE_GNU_LD
> >#define __environ environ
> >#endif
> >
> >char *
> >getenv (name)
> > const char *name;
> >{
> > size_t len = strlen (name);
> > char **ep;
> > uint16_t name_start;
> >
> > if (__environ == NULL || name[0] == '\0')
> > return NULL;
> >---------------------------------
> >
> >Here is it disassembled, I can't figure out what
> >that call to qsort+336 is all about and the use of
> >ebx. Could that be how environ gets set up?
>
> I think that the "qsort" reference is bogus. The sorted list of symbols
> for my particular libc.so.6 (2.2.3, built here) shows this:
>
> 0002f150 t _quicksort
> 0002f5de t Letext
> 0002f5e0 t msort_with_tmp
> 0002f77c T qsort
> 0002f89b t Letext
> 0002f8a0 T getenv
> 0002f9b8 t Letext
> 0002f9c0 T putenv
> 0002fa45 t Letext
> 0002fa50 t __add_to_environ
> 0003002c W setenv
> 0003002c t __setenv
> 0003005c W unsetenv
> 0003005c t __unsetenv
> 00030174 W clearenv
> 00030174 t __clearenv
> 000301fc t free_mem
>
> Perhaps the compiler put a very short internal subroutine _before_ the
> entry to getenv().
>
> >
> >-----------------------------
> >Dump of assembler code for function getenv:
> >0xa006fcd4 <getenv>: push %ebp
> >0xa006fcd5 <getenv+1>: mov %esp,%ebp
> >0xa006fcd7 <getenv+3>: push %edi
> >0xa006fcd8 <getenv+4>: push %esi
> >0xa006fcd9 <getenv+5>: push %ebx
> >0xa006fcda <getenv+6>: sub $0xc,%esp
> >
> > (this next part I don't understand)
> >
> >0xa006fcdd <getenv+9>: call 0xa006fcd0 <qsort+336>
> >0xa006fce2 <getenv+14>: add $0xf516a,%ebx
> >
> >(I think this is the strlen)
> >
> >0xa006fce8 <getenv+20>: mov 0x8(%ebp),%eax
> >0xa006fceb <getenv+23>: mov (%eax),%dl
> >0xa006fced <getenv+25>: lea 0x1(%eax),%eax
> >0xa006fcf0 <getenv+28>: test %dl,%dl
> >0xa006fcf2 <getenv+30>: jne 0xa006fceb <getenv+23>
> >(end of strlen)
> >
> >
> >0xa006fcf4 <getenv+32>: mov 0x8(%ebp),%edx
> >0xa006fcf7 <getenv+35>: sub %edx,%eax
> >0xa006fcf9 <getenv+37>: dec %eax
> >0xa006fcfa <getenv+38>: mov %eax,0xfffffff0(%ebp)
> >
> >(is this -below- the check for __environ == NULL)
> >
> >0xa006fcfd <getenv+41>: mov 0x884(%ebx),%eax
> >0xa006fd03 <getenv+47>: mov (%eax),%edx
> >0xa006fd05 <getenv+49>: test %edx,%edx
> >0xa006fd07 <getenv+51>: je 0xa006fd58 <getenv+132>
> >
> >(this -below- looks like the check for name[0]==0)
> >
> >0xa006fd09 <getenv+53>: mov 0x8(%ebp),%ecx
> >0xa006fd0c <getenv+56>: cmpb $0x0,(%ecx)
> >0xa006fd0f <getenv+59>: je 0xa006fd58 <getenv+132>
> >
> >
> >(Here is that call to setup ebx:)
> >
> >0xa006fcd0 <qsort+336>: mov (%esp,1),%ebx
> >0xa006fcd3 <qsort+339>: ret
>
> This, of course, is where the qsort+336 address comes from. I guess
> gdb doesn't like to print "symbol-number" addresses.
>
> The following are the test program and library. The program version
> is obviously the one that references environ. Removing the environ
> declaration and dummy reference near the end creates the other version.
>
> envdl-ref.c:
> ===================================================================
> #include <stdio.h>
> #include <dlfcn.h>
>
> main(int argc, char **argv)
> {
> extern char **environ;
> void *dlib;
> void (*env2)();
> char *str;
> int n;
>
> if (argc != 2) {
> fprintf(stderr, "usage envdl number\n");
> exit(1);
> }
> n = strtol(argv[1], (char **)0, 10);
> if ((dlib = dlopen("/tmp/libenv.so", RTLD_NOW)) == NULL) {
> perror("dlopen");
> exit(1);
> }
> str = dlerror();
> if (str) {
> fprintf(stderr, "%s\n", str);
> exit(1);
> }
> if ((env2 = dlsym(dlib, "env2")) == NULL) {
> perror("dlsym");
> exit(1);
> }
> str = dlerror();
> if (str) {
> fprintf(stderr, "%s\n", str);
> exit(1);
> }
> printf("env2: %08x\n", env2);
> env2(n, environ);
> sleep(15);
> return 0;
> }
> ===================================================================
> This is the "library".
> env2.c:
> ===================================================================
> #include <stdio.h>
>
> void
> env2(int n)
> {
> extern char **environ;
> extern char **__environ;
>
> printf("At env2(%d)\n", n);
> fprintf(stdout, "&environ: %08x\n", &environ);
> fprintf(stdout, "environ: %08x\n", environ);
> fprintf(stdout, "&__environ: %08x\n", &__environ);
> fprintf(stdout, "__environ: %08x\n", __environ);
> fprintf(stdout, "*environ: %08x\n", *environ);
> fprintf(stdout, "*environ: %08x\n", environ[0]);
> fprintf(stdout, "*environ: %08x\n", environ[n]);
> fprintf(stdout, ">> %s\n", environ[n]);
> return;
> }
> ===================================================================
> This stuff was built with:
>
> gcc -g -o envdl-ref{,.c} -ldl
> gcc -g -o envdl-noref{,.c} -ldl
> gcc -g -fPIC -c env2.c
> gcc -g -shared -o libenv.so -Wl,--soname=libenv env2.o
>
> And executed in /tmp with:
>
> LD_LIBRARY_PATH=/tmp envdl-ref 7 &
>
> The "7" selected some random env entry and the backgrounding was to
> allow display of the /proc/../maps entry.
> --
> B. D. Elliott [EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
